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In this Issue 

To determine the composition of a complex mixture such as a biological 
sample or seepage from a toxic waste dump, chemists often use a combina- 
tion of gas or liquid chromatography and mass spectrometry. The chromato- 
graph separates the compounds that make up the mixture (see page 7 for 
an explanation) and the mass spectrometer gives information on the masses 
and structures of the constituent molecules. For many samples, especially 
those that are too nonvolatile or thermally unstable to be changed to a gas 
without decomposing, liquid chromatography is the best method of separa- 
tion. HP s latest-generation liquid chromatography system is the HP 1050 
Series LC modules, described on pages 6 to 50 of this issue, As R&D section manager Herbert 
Wiederoder explains in his introduction on page 6, the design of a high-performance LC system 
requires contributions from materials science, mechanics, chemical physics, optics, electronics, 
and software. The problems include the handling of liquids having a wide range of solvent properties 
at widely varying flow rates and pressures, control of mechanical components such as pumps, 
motors^ and valves, detection of chemical substances, and data handling. The HP 1 050 Series 
extends and refines HP's LC technology, emphasizing a common architecture and a standard 
design for all modules. A clever feature of the cabinet design is a built-in leak drainage system. 
When the modules are stacked, leaks drain from higher to lower modules without special adapters. 
There are three types of HP 1050 modules: solvent delivery system (pump module), autosampler, 
and detector The pump (page 24) is a simple and reliable series-dual-piston design with compen- 
sation for liquid properties and major physical side effects built into the pump control system. The 
autosampler {page 17) can automatically inject samples in a programmed sequence selecting 
from either the standard 21 -sample tray or the optional 100-sample tray. Two types of HP 1050 
detector modules are available (page 36). Both are absorbance detectors, which measure the 
light absorbed by the sample as a function of wavelength, producing a spectrum that is characteris- 
tic for a particular substance. The forward optics detector passes a single wavelength of light at 
a time through the sample, while the reverse optics detector uses white light, breaks the light into 
separate wavelengths after it goes through the sample, and detects ail wavelengths at once using 
a photodiode array. The HP 1050 Series firmware design is described in the article on page 44. 
In keeping with the standard-design philosophy, about 60% of each module's firmware is the 
same in all modules. To ensure that the HP 1050 Series modules met their quality objectives, a 
formal program was designed; it's discussed in the article on page 1 1 . 

In the 19B0s. computer technology became pervasive in companies large and smalL The 1990s 
will be the decade of the network, as companies interconnect their mainframe computers, personal 
computers, engineering workstationSn and manufacturing systems. Already, complex networks of 
computers and data communications equipment are common, usually containing equipment from 
many different manufacturers. These networks challenge their managers to find ways of monitoring 
and troubleshooting them, controlling the individual parts, measuring performance, and accounting 
for the use of network resources. The HP Open View family is a set of hardware and software 
products designed to address these issues in the management of open, standards-based, multi- 
vendor networks. "Standards-based" is a key concept, for it is the networking standards being 
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developed by the computer industry and international organizations like the ISO that nrtake multi- 
vendor networks both possible and manageable. The HP Open View family currently includes HP 
Open View Windows (see page 60), which provides a consistent, friendly user interface and an 
integrated environment for managing networks, the HP OpenView BhdgeManager (page 66) for 
managing LAN bridges^ the HP OpenView Data Line Monitor (page 71) for monitoring analog 
data lines, and the HP OpenView DTC manager (page 76) for configuring, diagnosing, and 
control fing datacom and terminal controllers. The HP OpenView story begins with an overview 
on page 51 . The HP OpenView network management architecture, solidly based on international 
and de facto industry standards, is discussed in the article on page 54. The article on page 85 
describes a pair of network management tools that were developed to test and refine the HP 
OpenView concept. These tools are used internally at HP but aren't available as products. 

A Word about Cards 

With the December 1989 issue, we sent a card to our U.S. readers, asking them to confirm 
that they wanted to be on our mailing list. Because a last-minute change of plans wasn't properly 
communicated to our U,S, pnnter. most readers received the wrong card, which implied that they 
had recently become subscribers. We'd like to apologize to the hundreds of long-time readers 
who were offended or confused by this error. We'd also like to thank the many readers who 
returned their cards with kind comments. 

R.P. Dolan 
Editor 

Cover 

Behind the front door of the HP 1050 Series liquid chromatograph quaternary pump module is 
the four-way proportioning valve and the dual-piston pump. The overlay is a pair of chromatograms 
made using an absorb an ce detector at two different wavelengths. 



What's Ahead 

In our next issue, we'll have articles on the design and capabilities of the HP SoftBench integrated 
software development environment, on the HP OSF/Motif window manager and the HP OSF Motif 
widget library; on the HP particle beam interface for combining liquid chromatography with mass 
spectrometry, and on HP's membrane probe technology for testing integrated circuit wafers. 
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A New Modular High-Performance Liquid 
Chromatograph 

The HP 1050 Series of modules refines and extends tHP's 
LC technology, emphasizing a common architecture and 
a standard design for all modules. 

by Herbert Wiederoder 



HIGH-PERFORMANCE LIQUID CHROMATOGRA- 
PHY [HPLG), as a separation technique for nonvola- 
tile substances in mixtures, has a wide range of ap- 
plications in the industrial world today. Over the last de- 
cade, instrumentation for liquid chromatography has 
evolved towards higher flexibility, greater ease of iise» and 
higher reliability. 

Designing an HPLC system requires a high degree of in- 
teraction between various disciplines, including mechan- 
ics, materials science, chemical physics^ optics, electronics ^ 
firmware, and software. Problems that must he solved in- 
clude the hand ling of liquids having a wide range of solvent 
properties at flow rates from 1 /xl/rnin to 10,000 ftl/min and 
pressures up to 400 bar, control of mechanical components, 
iietection of chemical substances, aiid data handling. 

How these problems were solved to provide a flexible, 
easy to use , easy to handle , and high! y rel iablc HPLC system 
for HP's latest-generation liquid chromatograph will be de- 
scribed in this and the following articles. The design of 
the new system, called the HP 1050 Series Liquid Chroma- 
tography Modules, takes a new modular approach, starting 
from the technology of the HP 1090 LC family.^ 

HP 1050 Architecture 

An HP 1050 Series module is an independent instrument 
wuth specific user, hydraulic, and communication inter- 
faces. Each module hes its own power supply and enclo- 
sure ^ The combination of the modules provides the func- 
tions necessary to do HPLC. The information flow and 
solvent flow in a typical chromatograph are shown in Fig. 1 . 

The HP 1050 architecture breaks down the modules ac- 
cording to the functional blocks shown in Fig. 1. Fig. 2 
shows the HP 1050 Series modules. The separation takes 
place in the column^ w^hich is a tube filled with porous 
materia L The typical column supported by the HP 1050 
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Separation 
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has an internal diameter of 4.6 mm and a length between 
100 and 250 mm. The column is placed in the solvent 
preparation module, which is part of the solvent delivery 
system. Two versions of solvent delivery modules are avail- 
able: an isocratic pump version and a quaternary pump 
version. If the quaternary pump is chosen, the solvent prep- 
aration option is required. It is typically placed above the 
pump and serves several functions, as described in the 
article on page 24. 

The sample (sample volume typically between 0.1 and 
100 jul) is introduced either manually by a valve or automat- 
ically by a separate module called the automatic liquid 
sampler (ALS). Samples are typically stored in 2-ml vials. 
Up to 119 vials can be automatically processed, as de- 
scribed in the article on page 17- 

The detector is also a separate module. Two versions of 
absorbance detectors are available: a variable wavelength 
detector [VWD) and a multiple wavelength detector [MWD). 

Standard Module Design 

Before the individual modules went into the detailed 
design phase, a common internal and external architecture 
for all the modules w'as developed, and standards were 
established for all modules to follow. Standardization was 
a crucial issue. It provides several advantages* including: 

■ Provides a family look for the customer 

■ Gives the customer the freedom to arrange the moduJes 
to optimize the use of bench space 

■ Lowers the cost of the individual modules 

■ Allows new^ production processes for medium-volume 
products 

■ Increases R&D productivity and efficiency 

■ Makes design for manufacturing easier 

■ Defines clear interfaces betw^een the functional modules 
for a liquid chromatograph. 
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Rg. 1. Functionsi diagram for 

high-performance liquid chroma- 
tography (HPLC). 
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An Introduction to Liquid Chromatography 



A! the turn of tlie century the Russian botanist Tsvett was 
inv^siigating the composrtTon of the dyes in green plant leaves 
He made pelroleum ether extracis of freshly dried leaves and 
injected a small amount o^ such an extract on top oi powdered 
calcium carbonate, which was contafned in a verticalJy placed 
glass tube or column When he ffushed the column with a mixture 
of petroieum ether and alcohol, the dyes moved down through 
the column with different veJocities and finaily formed a sertes 
of green and ye! tow zones (see Fig. 1] He let the coiumn run 
dry and pushed the calcium carbonate out of it. He divided Ihts 
into pieces containing the different zones, and dissolved the 
dyes (which are green chlorophyls and yellow caratenoids) from 
the adsorbent {the calcium carbonate) with an appropriate sol- 
vent. 

Sample 



^^^^ 



-Top of Column Bed 



Separated Componants 



-Column Packifig Material - 




Wall - 



IF 



Start: Sample Introduced 
at Top of Coiumn 



-Column Outlet- 



FT 



End: Components 
Separated 



Fig. 1 Pnncipie of chromatography. 



In this way Tsvett physically retrieved [he individual compo- 
nents from a mixture. He called this separation technique chro- 



matography, not because "tsvett" is Russiar^ for cotor (Qreek 
cfiromos' = color), and not because the zones in his first exper- 
iments were visible as colored rings (he immediately recognized 
that the technique is suitable for both colored and uncolored 
compounds), but because the mixture of dyes was separated 
obeying &ome physical law. like Ihe colors in a rainbow. He drew 
this parallel because the dyes were always separated in the 
same order when he used the same composition of the flushing 
solvent. 

In all chromatographic techniques two phases are involved: 
(T) a stationary phase, which is the column packing material, the 
calcium carbonate in Tsvetfs experiments, and (2) a mobile 
phase, the eluent, v^hich is the liquid that is flushed through the 
column bed, the petroleum ether/alcohol mixture in Tsvett's ex- 
periments. The components in the sample mixture are separated 
because their interaction with the stationary phase is different 
Because this interaction mechanism can be influenced in many 
ways, both by changing the stationary phase material and by 
changing the mobile phase composition, chromatography has 
become one of the most powerful and most important chemical 
analysis techniques. 

In the last decades, liqutd chromatographic techniques have 
improved dramatically. II is now very unusual for the column 
packing material to be removed after each experiment. Instead, 
the column is flushed until all compounds of the sample mixture 
have left the column outlet. The stationary phase can then be 
used again; this is necessary for routine analysis. 

The compounds that leave the column outiel are now usually 
detected on-line. Many powerful detection techniques have been 
developed, of which the UWvisible absorption detector is the 
most widely used. Other detector types are fluorescence, elec- 
trochemical, radiometric, conductance, refractive index, polari- 
metric, and mass speclrometric. This wide choice of detectors 
includes types that offer universal detection (e.g., refractive 
index) or types that detect very specific functional groups with 
increased sensitivity (e.g., fluorescence), This is helpful in iden- 
tifying compounds. 

[ca ntlngeci on nex[ pagg) 




Fig. 2. The HP 1050 Series Liquid 
Chroma to graphy Moduies. 
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The gravitational force Tsvett was using toelute the compounds 
for his separation does not always give very reproducible results. 
Deviations rn colunnn resistivity (caused, for example, by changes 
in the column bed or by temperature effects) lead to changes 
in the flow rate of the eluent. This means that the same compound 
may elute from the coiumn at varying times. Modem pumping 
systems can supply liquids with hardly any pulsation and with 
very high accuracy, enabling compourtds to eJute from the col- 
umn at very reproducible times (relative standard deviation 
<0,5%). This retention time ss one of the most important param- 
eters in the identifiGation of compounds. Even more flexibility 
(and complexity) in the separation process can be achieved by 
changtng the solvent composition during the analysis, For this 
purpose highly sophisticated programmable-gradient pumps are 
available. 

Once the hydrodynamics of the separation were understood 
and written down in some fundamental equations, it was clear 
that the proper choice of column packing material can improve 
the separation considerably. The smaiter the diameter of the 
packing material particles, the better the separation efficiency, 
The practical limit is near 1 to 2 ^m, with the most common 
particle diameter nowadays being 5 fim. 

The partJcie diameter should be constant within narrow toler- 
ances: the more uniform, the better. With these small particle 
diameters, with column inner diameters of 2 to 5 mm, with com- 
mon lengths of 10 to 25 cm, and with eiuent flow rates of 2 to 
2.5 ml/min, the pressure drop can be several hundred bar. There- 
fore, glass IS not suitable anymore for the column tube material. 
Mow. tubes of stainless steel are common. As a consequence, 
the pumping systems have to be able to deJiver pressures up 
to approximately 400 bar. In addition, the particles must have 



high mechanical strength. Therefore, most column packing ma- 
terials have a silica gel core. This silica gel is usually chemically 
modified and stabilized by attaching less-polar groups to it. This 
makes the separations from column to column more reproduci- 
ble, and makes fine tuning of the stationary phase to different 
separation systems possible. 

All chromatographic techniques use the fact that the detector 
signal is proportional to (preferably linear with) the concentration 
of the compound that is being detected. This means that the 
amount injected onto the column must be supplied with very 
high precision and reproducibility. Either fixed-volume (manual) 
injectors are used, or variabte-volume (automatic) injectors. In 
the latter, the injection system is combined with a sample ex- 
changer, which allows automatic analysis of a large number of 
samples. 

Some samples are not thermally stable. For such samptes it 
may be necessary to cool the sample to approximately 4''C. 
Cooled autosamplers are now available. 

The separation kinetics usually are temperature sensitive. 
Therefore, thermostattc control of the column temperature is 
necessary for the highest reproducibility of the retention times 
and the peak shapes. 

All of these contributions have made liquid chromatography a 
very powerful and reproducible technique, so much so that the 
modern version is often referred to as high-performance liquid 
chromatography, or HPLC 



Henry J. van Nieuwkerk 

Chemist 
Watdbronn Division 



As a result of standardization in the hardware and firm- 
warCt ttie number of parts has been significantly reduced 
compared to the HP 1090. The HP 1050 has about 60% 
fewer part numbers than the HP 1090. About 60% of the 
firmware code in each module is the same in all modules. 

The external design for all the modules conforms to HP 
corporate product guidelines. ^^11 modules have the same 
footprint [325 mm wide by 560mm deep] and user interface 
style. 

Ease of access to electrical and hydraulic interfaces was 
an important design goal. This resulted in a design in which 
all electrical connection. s are made from the rear and all 
hydraulic connections ai'e made from the front. Because 
the instruments are in contact with a w4de range of solvent 
properties, for safety reasons a special leakage interface 
was developed to handle the solvent in case something 
leaks inside a module. 

The internal architecture was driven by several design 
goals, including design for manufacturability, standard in- 
ternal structure, easy accessibility to routine maintenance 
partSt and user interaction from the front. 

Design for manufacturability was an important issue for 
the enclosure. The enclosure is based on a chassis that 
holds all the mechanical, electrical, and cooling assemblies 
and the front panel. The cover, fixed with Iw^o screws, 
completes the enclosure. 

Fig. 3 shows the internal structure of all of the modules. 
The back part contains up to six standard- si zed printed 
circuit boards including a standard power supply. All of 
the boards have their ow^n rear panels and are fixed in a 



flexible card cage. The card cage isolates the electronic 
section from the mechanical and cooling section and makes 
the cable connections to the mechanical parts. The mechan- 
ical sections are arranged to provide access to the routine 
maintenance parts from the front. The cooling system is 
designed to channel the air flow from the front to the back. 
This makes it possible to slack the moduJes without sac- 
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Fig. 3, interna} module structure. 
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Industrial Desi^ and Ergonomics 



'ITiose who want to be sLlccessfu^ in intemaiKrial mafkets 
need wel(-deagned products, However, design is more itian iust 
that. It is part of the product s quality, rt communicates the com- 
pany's basic values^ and therefore it may be an important criterion 
in the purchasing decision fof high-tech products '^ One effect 
of changing social values ts that users are incfeasingly more 
selective in their demands on ihB human interfaces of products 
TlTey require much more than lust good styling. The chafienge 
for the industnal design of the HP 1050 Series Liquid Chromaiog- 
raphy System was to Keep pace with this trend 

Customer visits pfayed a maior part in the industrial design 
investigation. By observing and interviewing users, we were able 
to determine our own instruments' weak points as well as those 
of competitive machines: the instruments were loud, maintenance 
was complicated, access to the inside of the instrument was 
difficult, the instrument required large amounts of bench space, 
compatibility with other instruments was iow, the user interface 
was easily misunderstood. Combining this list of customer needs 
with the technical requirements of other engineers in the team, 
the industrial designers were able to develop several alternatives 
for the user interface. 

We chose the HP guidelines for computer products as the 
bas^s for the industnal design of the HP 1050. This makes the 
HP 1050 stackabte like HP desktop computer products. Stack- 
abfiity. however, required that the internal components be reor- 
ganized, since usually instruments of this sort are repaired or 
modified from the top, by removing the top of the case. The 
solution was to spirt the internai components into two separate 
areas: the electronics in the back in a card cage, accessible 
from the rear, and the mechanical components at the front, ac- 
cessible by opening the front door. 

To design a simple and common user interface, we aimed to 
standardize as much as possible, which of course required con- 
siderable effort in coord inaiing our activities, A cardboard modeE 
showed external dimensions and aided in estimating the amount 
of space required on the lab bench. 

The realization of the concept had to meet not just the functional 
demands of the instruments Many improvements to the front 
panel had to be made, srnce they were not covered by the 
guidelines A few examples are given here 

The front panel consists of seven plastic moldings, six of which 
are common to all modules. The door is the only piece that differs 
from module to module The keyboard is the only piece tixed by 
screws — two in all All the others snap together. The door can 
be swung open to obtain access to the parts requinng mainte- 
nance or modification during operation. The keyboard as- 
semblies for all the 205-mm'tafl modules are differentiated by 
individual silkscreens beanng the module-speciftc key functions 
only The base of the keyboard is intended to act as a handle 
during transport and as a guide for the capillaries — the liquid 
connections from one module to the next A similar treatment in 
the metal work at the rear means that the instrument can be lifted 
by one person, unaided. 

A difficult problem was posed by leaks that may occur in any 
liquid chromaiograph Most instruments leave the solution of this 
problem to the customer. The HP 1050, on the other hand, offers 
a contnbutfon to the safety and the organization of the instrument 
by enabling the operator to jnstali capillaries in guiter-iike chan- 
nels, which collect any leaks and direct them to a waste pipe. 
The drainage system (Fig. 1) consists of a leak basin, a leak 
sensor, and vertical channels running inside the front panel of 
each module. A channeE in one module directs liquid to the 



For Leak Liquid 
from Module Ai^ove 



For Capillaries 




To Waste Bottle m r^ext Module 
Fig. 1 . Leak drainage sysfem, 

channel in the next lower moduie without the need for special 
adaptors, so that only the lowest module in the stack needs to 
be connected to an external waste pipe, Any of the modules can 
be placed at the bottom ol the stack. These leak interfaces are 

easy to remove for cleaning, which may need to be done more 
frequently when using liquids with high concentrations of salts, 
which may crystaNrze out 

Ergonomics 

A user intertace can only be considered well-designed when 
it can be operated without error, quickly, and without personal 
danger. Two examples are worthy of mention with respect to the 
HP 1050- The opening in the side of the autoinjector module 
ailows the injector to be loaded vta robotics, for example Ihe 
autosampler, but primarily this opening is for loading the auto- 
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Fig. 2. Viewing angles for the keyboard. Heights are in mil- 
If meters above the floor. 

Injector with the sample tray by hand. The tray is designed such 
that it always fits nghl the first time, ti is l<eyed such that there 
is automalically only one way to lower it onto the spindle — Kn the 
zero starting point for subsequent rotation during sampling, This 
avoids incorrect mounting and prevents injunes. The wide open- 
ing in the autosampler and the tray's grip-fast handle avoid han- 
dling errors such as slippage or impacts while placing the Iray 
En such a confined space, 



The second exannple is the keyboard. We had to find the best 
compromise among several parameters Every module can be 
installed at the top or at the bottom of the stack, can be installed 

on a high or a low bench, and might be operated by a tail (95%) 
or a short (5%) person, both of whom should be able to read 
the display, Different mounting angles were simulated in several 
tests of the keyboard and display (Fig. 2), as were different types 
of displays Tfie best combination was found to be a vertical 
vacuum fluorescence display with a blue/green filter and a touch- 
sensitive membrane switch keyboard inclined at 1 degrees from 
the vertical We decided to avoid using grey areas around the 
keys since we wished to give the impression that the keyboard 
would be simple to use (there are 35 keys in the confined space 
of each keyboard) and to reduce the likelihood of erroneous input. 

Conctusion 

The HP 1 050 LC system requires little bench space since it 
stacks easily. All important parts are easily accessible and the 
user interface is easily understood, comfortable to use yet func- 
tional. The automation interface and case concept are as future- 
proof as we could make them, and last, but not least, the product 
has an attractive, up-to-date appearance. We are pleased that 
the HP 1 050 has been awarded international design prizes. 
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rificing the cooling. The front part of the module contains 
the user interface, a door for access to the mechanical parts, 
the hydraulic interfaces for the capillariest and the leakage 
interface. 

The technical details of how the individual modules use 
the standard components and are designed for their specific 
requirements are covered in the olJier HP 1050 articles in 
this issue. 
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Quality Engineering for a Liquid 
Chromatography System 

For the HP 1050 Series LC system, customer expectations 
were translated into measurable quality goals, which were 
then verified by special test methods, 

by Helge Schrenker and Wolfgang Wilde 



CUSTOMER SATISFACTION is the ultimate bench- 
mark for product quality. This sounds straightfor- 
ward, but it is far from a trivial task to translate the 
customer's voice into product quality. It requires finding 
out, in quantitative and measurable terms, what quality 
properties the majority of potential customers want, trans- 
lating these customer expectations into terms, measures » 
and goals that are meaningful to design and manufacturing 
engineers, and assuring throughout the design and transfer 
phases that these goals will be met by the future product. 

For two product generations, we have been using the 
same set of quality criteria. With each generation, we have 
refined the measures and test methods, Fig. 1 shows the 
key quality criteria and measures that were applied to the 
HP 1050 Series Liquid Chromatography System. Using 
some of these criteria and measures as examples, we will 
briefly describe how specific quality goals for the HP 1050 
Series were set and verified through specially developed 
test methods. 

Setting Quality Goals 

Design goals for each of the five quality criteria listed in 
Fig- 1 were set using three information sources: 

■ A specific, well-aimed customer survey 

■ inputs from senior sales and service people on their per- 
ceptions of customer expectations 



Quality Criteria 



Performance 



Reliability 



User Frtendriness 



Serviceability 



Regylations Safety 



Measures 



Conformance to Published Specifications 
Result Precision and Confidence 
ConsJstefYcy over Longer Operating 
Periods 

Mean Time between Failures (MTBF) 
Useful Life of Product 

Time for Standard Tasks, 

Unfamiliar Familiar Operator 
System Installation Time 
Number ot Cables and CaplJIsafy 

Connections 
Noise Emissfons 

Repair and Maintenance Cost to the User 
Average Downtime per Year 
Mean Time fo Repair 

Conformance to Relevant Standards 



■ Analysis of presently available LC instrumentatioa 
(strengths, weaknesses, potential for iniprovements). 
The customer survey was aimed at gathering current cus- 
tomer F3xpeetation data on such sensitive criteria as reliabil- 
ity, uptime, measurement reproducibility, cost for service 
and maintenance, and so on- Since our resources were 
limited, we decided to sur\^ey only a selected, representa- 
tive sample of about 100 individuals from our customer 
base. Our experiences with such small samples in earlier 
sur\^e3'S were good. The advantages are low cost and the 
possibility of enhancing the return rate and results by a 
mix of mail, telephone, and personal survey methods. 

We achieved excellent consistency of survey results. The 
responses, even to sensitive questions, were very consis- 
tent, and compared well with the perception of senior HP 
field and marketing people and with the results of a 
thorough technical annlysis of a current similar product. 
(The technical analysis was an analysis of the failure modes 
of a current product assuming a complete redesign with 
elimination of all known failure mechanisms for which 
solutions seemed feasibled 

It wEis interesting to learn how dramatically customer 
expectaliuns for the useful life of the product can change 
from generation to generation. Expectations for product 
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Fig. 1 . Key quality critena and measures applied !o define 
and verify !he quaiity of the HP 1050 Series LC system, 
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lifetime were more than three times as long as the equiva- 
lent data from a survey we had conducted about nine years 
ago. Setting the right goal for useful life is critical for 
mechanical assemblies. Higher-lifetime components are 
often more expensive, so overdesign must he avoided. On 
the other hand> early wear-ovU means dissatisfied custom- 
ers. 

One important aspect of surveys is the statistical evalu- 
ation of the response data. In this survey, the responses of 
customers from different markets and different environ- 
ments for such criteria as expected reliability, service cost, 
and the like were consistent enough to justify calculating 
the mean and confidence interval. This was not so for some 
other results, for example the expected analysis precision, 
where the responses differed widely based on the respon- 
dents' major applications. This was not surprising, since 
a QG analysis of a drug may require a precision level of 
Oh 3%, while in an analysis of a biological sample in a com- 
plex matrix, w^hich requires several sample preparation 
steps that are all prone to statistical variation ^ overall ex- 
pected analysis precision may be only 5 to 10%. In such a 
situation it is meaningful to plot a cumulative distribution 
of the survey results as shown in Fig* 2. This plot indicates 
what percentage of potential users could accept a product 
designed for a certain performance level (assuming that 
users with lower performance requirements would accept 
the product as long as the price were acceptable). This plot 
is useful for cost/performance optimization. 

Similarly, design goals were defined for each of the qual- 
ity criteria listed in Fig. 1, resulting in a set of beiiciunarks 
for HP 1050 Series quality. 



tem levels, we do mainly the second type of strife testing. 

The same product-level stress conditions are also used 
to check the robustness of specifications against aging. This 
is possible because we now have more than eight years of 
experience with this type of test, and we can verify by 
comparison with field failure results that a typical acceler- 
ation factor for a product under our stress conditions lies 
between 5 and 10. For example, Fig. 3 shows the wave- 
length calibration accuracy of the HP 1050 Series diode 
array detector over a simulated operating time of two years^ 
The result is better than ±1 nm^ equivalent to the design 
goal. Fig, 4 is a flow chart of the test procedure. The reason 
for the additional tests with subassemblies is that, to accel- 
erate a special failure mechanism, specific stress conditions 
may be necessary and/or more data for failure analysis may 
be needed. 

As mentioned before, we want to be able to predict relia- 
bility, that is, reach a good estimate for the annualized 
failure rate (AFR) during and after completing the test. 
There are many obstacles to achieving high confidence 
levels. One has the option of either testing many products 
in parallel or of applying high stress to a few samples to 
get results in a reasonably short time. Neither alternative 
is ideal; it is too expensive to test a large number of com- 
plete systems, and very high stress levels risk introducing 
unrealistic failure mechanisms. Another problem is deter- 
mining the acceleration factor for a product under high 
stress. We decided to stay with our moderate stress level 
and find a good model to monitor reliability growth. We 
selected the Duane model. It is an advantage of such models 



Reliability Verification 

There are two main approaches to strife (stress + life) 
testing. The first is the test-to-fail philosophy: the stress 
applied to a product is increased until a failure occurs. 
The aim of this test type is to find design weaknesses using 
high stress levels. The second approach is a strife test with 
fixed stress conditions (constant acceleration factor*] at a 
more moderate stress level, w^hich most likely finds only 
failure mechanisms potentially occurring under normal 
operating conditions. The focus is not only on finding de- 
sign weaknesses but also on being able to predict reliability 
(annualized failure rate, or AFR), On the product and sys- 

'Accelafatton factor is the ralio af Iha annualized faiJufe rate under stress conditions to the 
annualized iailure r^Je in noimial use. 
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Fig. 3. Plot of the wavelength calibration accurscy of the HP 

1050 Series diode array detector. The test time of 64 days 
corresponds to over two years ofnormai operation, assuming 
an acceleration factor of five and 3500 operattng hours per 
year. 
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Fig- 4. Test procedure for strife testing under fixed stress 
condittcns. For additionai tests with subassemblies, stress 
copditiQns are adapted to the faiiure mechanism. 



12 HEWLETT. PACKARD JOURNAL APRIL 1990 



)Copr. 1949-1998 Hewlett-Packard Co. 



that t&st data for a product under test is accumulated (giving 
more confident results) to calculate an instantaneous AFR. 
which successively improv^es. The model also indicates 
the effectiveness of the reliability program.* 

For the HP 1050 Series modules we decided on the foJ- 
lowirtg constant stress parameters: temperature cycling be- 
tween 5 and 70"^, line \'oltage and frequency variations, 
power on/off cyclings and instrmnent'Specific stress for ac- 
celerated operation (for example, repetition rales for the 
injector, pressure for the pump, etc.)- For any failure found 
during the test we did an analysis of the failure mechanism 
and implemented the fix. The resultant improvement of 
the reliability of the instrument using this test-fix-test 
method is called reliability growth. For data e%^aluation w^e 
used the Duane model, which assumes that the cumulative 
mean time between failures [MTBFc] is proportional to x"*, 
where x basically is the test lime and a is the reliability^ 
growth estimator.^ Plotting MTHFj^; against x on log-log 
paper leads to a straight line with the slope a [see Pig, 5), 
With these results we were able to predict an AFR at the 
time of release of the HP 1050 Series- Now, mare ihan a 
year after the introduction of the HP 1 050 Series, we have 
sufficient data to check this predicted AFR. Analysis shows 
that we are within ±10% of the predicted AFR for the HP 
1050 pump. These results encourage us to continue using 
this method. 

User Fnendliness 

In 1986 we started to develop measures and test methods 
for user friendlirtess, to be included later in the design 
objectives for new product development. The first step was 
to assemble a group of experienced people from marketing, 
R&D, sales, and service, and brainstorm on factors relevant 
to the user friendliness of an analytical instrument. The 
result was a list of about 20 factors that all seemed more 
or less relevant. To narrow these down to a few testable 
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Time for First-Time User ■ Slowest First-Time User 



Time for Experienced User • Average 

▼ Quickest First-Time User 



Fig, 6, Resutts of the pitot user friendiiness test for four diffBr- 
ent test modules corresponding to four different sets of operat- 
ing parameters. The n}easured quantity ts tf}e time for correct 
errtry and vehftcation of the respeoiive parameter set 

measures that are most important for our customers, we 
interviewed some large industrial customers. According to 
chemists in anal}^ical labs, three main factors determine 
their requirements for ease of operation: 

■ Most instrument operators are nonprofessionals 

■ There is relatively high operator turnover 

■ The sample mix requires frequent changes of analysis 
method. 

User friendliness is mainly perceived as the effort (that 
is, time) required by a relatively untrained operator to set 
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Fig, 5. Duane plot tor the HP 1050 Series qualBrnary pump, 
reiating cumufstive mean time betwew failures MTBFc to test 
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Fig. 7. HP 1050 Series user friendliness measures. 
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Design for Manufacturing 



The devalopment of a new product means a challenge for 
manufacturing, because new processes and manufactunng 
methods are introduced. The inciusion of three prodtjction en- 
gineers in the HP 1050 Series devafopment team from the begin- 
ning ensured that manufacturing experience was reflected in the 
design 

JIT (just- in -time) and design-for-manufacturabi]ity methods 
were applied consistently, and had a decisive impacl on the struc- 
tured design of the HP 1050 Serfes modules. A product-oriented 
production JayouE guarantees low production costs, increased 
productfvity, and high flexibility. The number of assembly levels 
was reduced to three, thus, assembly, material supply, and order 
handling could be simplified significantly. Production iine person- 
nel were trained to assemble and test the new modules in the 
prototype phase and were able to provide important suggestions 
for improvements to the development team, Special emphasis 
was put on the development of tools and test equipment. 

Automated Testing and Networking 

Increased productivity and continuous evaluation of product 
quality are based on automated tests HP 9000 Series 300 Com- 
puters and HP Vectra Personal Computers are used as controllers 
to test the HP 1050 Series modules and assemblies during the 
course of the manufacturing process. 

Test data is evaluated both to increase product quality and to 
supply timely informalion to control the manufactunng process 
by statistical methods. A compcehensive network strategy sup- 
ports the computerized tests in the manufacturing area (see Fig. 

1). 

All LC statfons are connected to a central HP-UX station by 
an HP SRM (Shared Resource Manager) network. At the central 
station, all test data is collected and stored on a data base, 
Information is retrieved for monthly quality reports and analyses. 
Thus, the responsible production engineers can react to prob- 
lems quickly and properly. 

Another advantage of the SRM network is central test program 
management. This makes sure that all programs are subject to 
a weekly backup cycle. 



Dally Results, 
Backup 



Stations 



/ 



*1 "\-\ 



Test Data Base 

Program SRM 



Reports 



Resutt File 




Raw Data 
on Disk 



Weekly 

Test Program, 

Backup 

Rg. 1. HP 1050 Series production computer network. 

AH test stations were already working at the beginning of the 
production prototype phase. This feedback enabled production 
engineering and R&D to receive and evaluate important informa- 
tion on manufacturabiiity and testability at an early stage. This 
made it possible to improve the tests and increase their efficiency 
by continuous development, 

Continuous Flow Manufacturing (CFM) 

A prerequisite for continuous jusl-in-tlme (J!T) production js a 
material-flow-oriented line layout (Fig. 2). The material for HP 
1050 production is conveyed directly from the stockroom to the 
line by a material elevator, Thus, long and awkward material 
fJows are avoided and the location af the material is known at all 
times. 

The straightforward matenal flow is also suppohed by the ma- 
terial list structure forth© HP 1050 modules, which has only three 
levels at most. 
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Fig. 2, The line layout corre- 
sponds 10 the material iist struc- 
ture. 
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Fig. 3. insiaiSing a dstrnper screw. 

Robotrcs 

In tne HP 1050 pumping systern, the State of the membrane 
between the damper head and the damper body determines the 
performance of the high-pressure damper, To avoid placing this 
membrane under incorrect tension, it is necessary to tighten the 
eight screws of the damper in different sequences with increasing 
torques, The use of the high-pressure damper in both the HP 
1090 and the HP 1050 led to a drastic increase in the number 
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Screwing 

Device 
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Rg. 4. Robot smtfon data f^ow 

of units. To maintam qually, the manual screwing procedure 
formerly used had to be abandoned 

To ensure a stable leveJ of quality, the tightening is now done 
by an eJectronicaily controlled screwing device connected to a 
robot (see Figs 3 and 4) This robot is also used for preassembly 
of the high'pressure damper The programs for the screwing 
device and the robot were written on an HP Vectra personai 
computer and are retrieved from the hard disk as needed. By 
monitoring the screwing procedure — tn particular the torque, the 
angle of rotation, and the screw-in depth — each irregularity of 
the damper and screw threads can be detected. 

Heiko Breckwotctt 

Manfred Seitz 

Production Engineers 

Waldbronn Analytical Division 



up and nin an analysis. 

Based on this information, we developed a test method. 
It consists of defining standard tasks for the unit under test 
and measuring the time required to perform these tasks by 
test persons without any operating experience on the unit 
under test, relative to very experienced operators. A pilot 
Ifj.st with 10 test persons was then performed on an LC 
workstation, to find out whether such a test is feasible and 
gives meaningful results, and wh^^il test procedure would 
work best> including: 

■ How much familiarization lor test persons is optimal (15 
minutes) 

■ Whether to do video monitoring or not (no) 

■ How to measure time (monitoring by an observer) 

■ How to record specific operating problems. 

Fig. 6 shows some results of this pilot test. Since we 
observed quite a wide range between the quickest and the 
slowest first -lime users, we decided to use both the average 
ratio and its range as our measures. Later tests showed that 
the range (slowest minus quickest first-time user, relative 
to experienced user) may be an indicator of the product's 
learnability.* In addition to these measures, the most fre- 
quejit operating problems experienced by the test persons 
were recorded as a basis for improvements of the user in- 
terface. 

The next step was to calibrate our test results against 
user perceptions of how user friendly the LC workstation 
was. Several hundred users were surveyed, with regard to 
the parameters tested, on how easy to use they perceived 
the workstation to be. The survey also contained questions 

'Aieo see Fig. lo 



that helped us define an average operator profile. This was 
important in selecting the right test persons. The survey 
results and the test results together gave us the basis for 
setting design goals for user friendliness of the HP 1050 
Series, fn addition, several other factors from our 
brainstorming list were included in the HP 1050 Series 
user friendliness measures (Fig, 7). 

The test procedure was successfully used by the HP 1050 
detector design team during user interface prototyping to 
improve the user interface. Fig. 3 indicates the significant 
progress in user perception that was achieved by this pro- 
cess. 

Finally, a test of the complete system was also done with 
13 test persons. Figs, 9 and 10 show some results of these 
tests. In most test categories, the HF 1050 system meets its 
design goals. We will complete the test with a user survey 
identical to the one answered by the test persons after 
finishing the test This calibration step will provide further 
data to compare test results with user perceptions, and will 
allow us lo make furtlier refinements in test methods and 
goal setting. 
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Fig. 9. Results of part two of the HP J 050 Series user friend- 
ilness test. 
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A Compact, Programmable Sample 
Injector and Autosampler for Liquid 
Chromatography 

The HP 1050 Series autosampler is capabie of manual or 
automatic injection from up to 11 9 sample vials at injection 
volumes up to 2000 microliters. 

by Wolfgang Kretz and Gerhard Fie 



Mi HE HP 1050 SERIES AUTOSAMPLER MODULE 
I (Fig. 1) is a compact, stackable, fully programmable, 
I microprocessor-controlled stand-alone unit designed 
to inject liquid samples automatically onto the column in 
a liquid chromatographic system. It performs routine 
analysis for quality control as well as analysis method de- 
velopment in research laboratories. It can either work in 
an HP 1050 Series LC system environment or together with 
HPLC modules from other instrument suppliers. 

The autosampler Is programmed via its front-panel 
keypad. A two-Iiiie display prompts the user in setting 
parameters and provides the required status information. 
The standard sample capacity is 21 sample vials, which 
can be randomly accessed for analysis. If required, the 
number of available sample locations can be expanded to 
119 by adding a dedicated sample tray with a robot-like 
manipulator. This tray also allows temperature control for 
its vial positions. 

The standard autosampler allows injection volume set- 
lings from 0,1 ^tl through 100 ^1 without the need to change 
any hardware. Optionally » the injection volume can be ex- 
tended to 2000 pd with a hardware modification. 




Design Goals 

From the beginning the main design philosophy was to 
offer our customers an instrument with ail major functions 
at a moderate price. When sample throughput or other 
requirements grow, the system can also grow, up to the 
highest degree of automation with a robotic system serving 
the autosampler. The main design goals were to provide: 
w A stand-alone module capable of working in any HPLC 

S3''stem 

■ A simplified hydraulic path to reduce maintainance and 
increase reliability 

■ A design that conforms to HP 1050 Series common de- 
sign guidelines for minimum footprint 

m Upgradahility to adapt to changes in customer demands 

■ A wide injection volume range to minimize the need to 
modify the instrument 

■ Maximum use of standard components to reduce cost of 
ownership 

m Access for a robotic vial handler 

9 Fast random access to minimi;?e the time required to 
carry out an injection 

■ No extra wash mode, thereby simplifying operation 

■ A maximally safe design with built-in leak drainage and 
leak detector. 



Metering Device 



From Solvent 
Delivery System 




Fig- 1* HP 1050 Series injector Btid autosampler modute The 
standard tray holds 21 sampfe vials. 



Waste 
Fig, 2. Prf^pare-tO'fnject corjdttion. 
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Mainframe 

The autnsampler follows the general design philosophy 
established for the HP 1050 Series. However, unlike the 
other modules, the autosampler has a large opening at the 
left front corner. This is to make the operating area easily 
accessible to the user, so that vials and trays can be inserted 
and removed very conveniently and simply- There is also 
access for the optional 100- via I tray and for a robotic system 
to manipulate the vials and trays. 

All HP 1050 modules are required to have random stack- 
ability, so special attention was paid to the mechanical 
stability of the autosampler module. As in the other mod- 
ules, there is strict separation of the chromatographic area 
and die electronic area. Manufacturability, electromagnetic 
compatibility, leak handling, and accessibility for repair 
were also important considerations throughout the entire 
development cycle. 

Theory of Operation 

The hydraulic path of the standard autosampler consists 
of three main assemblies: the six-port valve, the metering 
device, and the sampling unit. The six-port valve switches 
the solvent path to go through or bypass the other elements. 
The sampling unit acts as the interface to the viah It trans- 
ports the selected vial to the needle position » where the 
needle can move into the vial. The metering device then 
draws the programmed amount of sample into the system. 

A complete injection cycle .starting with an initial iiied 
system works as follows. The first step is the prep are- to -in- 
ject step [see Fig. 2). The six-port valve is switched to the 
bypa.<;s position so that the pump delivers flow directly 
onto the column and the remaining injector elements — me- 
tering device, sample loop, needle, and seat capillary — ^are 
bypassed. The liquid volume in this area, which is under 
a high system pressure of up to 400 bar before switching, 
can expand through the waste outlet of the valve. The meter- 
ing device plunger is moved to its front [home) position, 
displacing a small portion of solvent to waste. 

The next step is the load-sample step {see Fig. 3]. In the 
sampling unit the needle is lifted and the sample tray is 
rotated until the selected vial is directly under the needle. 
The needle is lowered into the sample liquid in the vial 
to allow the metering device to 6vuw up the desired volume 
by moving its plunger back a certain distance. The needle 





Frg. 4. tnject-and-run condition. 

is then raised again, the tray is moved to its home position, 
and the needle is moved onto the seat to close the sample 
loop. 

The final step is the inject-and-run step (see Fig. 4]. The 
six-port valve is switched to its mainpass position, which 
directs the flow back through the loop, which now contains 
the sample volume. The solvent stream transports the sam- 
ple onto the column, and separation begins. This is the 
beginning of the analysis. In this hardware conditi^on^ 
which is also the starting condition for the next injection, 
all major performance- influencing hardware is flushed by 
the solvent flow. Therefore, no additional flushing 
hardware and procedures are required- 
Extended injection Volume 

The standard instrument allows injection volumes up to 
100 fxl, which is the metering device volume. In some cases, 
larger voJumes are required. This can be achieved by re- 
peatedly drawing and storing partial volumes in the capil- 
lary connecting the seat to the valve* This mode of operation 
is called the multiple-draw mode. Before this can be done, 
the capillary must be extended with a larger one thai can 
hold the largest volume to be injected [see Fig. 5). 

In the multiple-draw mode the load-sample step is mod- 




Fig. 3. Lond-sampte condition. 



Fig, 5. 

lary. 



Loading a partial Eampfe into an extended seat capif- 
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ified. After drawing up and reseating the needle, the 
plunger is moved to the front position to place the 100->tl 
sample volume, or "plug," in the seat capillary. Then more 
sample is drawn from the vial and another 100-m1 sample 
plug is placed in the capillar\^ This is repeated for the 
required number of 100-^1 partial volumes. The last partial 
volume remains in the standard loop and the conventional 
inject-and-run step follows. 

Sampling Unit 

The sampling unit {Fig. 6) has two major functions. First, 
it opens and closes the sample loop by means of a movable 
needle and a fixed seat, which form a seal that can with* 
stand high pressure (up to 400 baj or 5800 psi). Second, it 
stores sample vials and moves the desired vial into the 
inject position. 

The stainless-steel needle, fixed in an arm, is moved up 
and down by a stepper-motor-driven leadscrew and guided 
by bushings on a shah. The lower needle position is deter- 
mined by a multifunctional optical sensor and a spring 
which is loaded when the needle moves onto the seat. This 
spring applies the required force to ensure a leakproof seal 
of the needle on its seat with zero motor current. The same 



optical sensor is also used to determine the upper needle 
position to ensure enough clearance for vials to be moved 
underneath. In addition, there is a missing-vial sensor, 
which is actuated only if a vnial is present when the needle 
moves down to the draw position. 

The sample vials are held in an internal tray with 21 
positions. The tray is manufactured as a precision plastic 
molded part. It can be removed very easily from the instru- 
ment to be loaded with sample vials. It can also be used 
as a sample container to be stored in a refrigerator. Several 
trays can be slacked easily and used to store vials on the 
lab bench. The driving mechanism for the sample tray is 
a stepper motor with a quadrature encoder for a position 
feedback sensor. The encoder resolution is 2000 counts per 
revolution, which corresponds to an angle of 0.18 degree. 
This allows very preci.se and reproducible rotation of the 
tray to the programmed vial location starting from the home 
position* Correct vial positioning eliminates the possibility 
of needle damage resulting from mlspositioning caused by 
accident or user interaction during rotation. In addition, 
the absolute positioning ensures that the correct vial is 
selected. The home position and presence of the tray are 
checked by a Hail -effect sensor which is actuated by a small 
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Fig. 6. Cutaway Vfew of the sampling unit. 
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magnet fixed in the tray. By evaluating the polarity of the 
sensor signal, two types of trays caa be distinguished. All 
functional parts are integrated onto a machined aluminum 
permanent-mold casting. 

Metering Device 

The metering device shown in Fig. 2 is a key element 
that strongly contributes to the precision of an antoinjector 
system. It must meter exactly the desired volume to be 
injected. The metering device consists of the analytical 
head assembly and the metering drive (Fig. 7), The analyti- 
cal head assembly connects with the sampling needle and 
the solvent delivery system. It contains a plunger to draw 
up the required amount of sample and subsequently inject 
it onto the LC column. The metering drive drives the 
plunger. 

To draw up a sample, the metering drive displaces the 
plunger in the head a certain distance. The metering drive 
is a high-precision linear actuator with a stepper motor 
driving a leadscrew via pulleys and a toothed belt. It is 
integrated in a carrier made of sheet-metal parts and 
aluminum permanent-mold castings, A vane mounted on 
the guiding nut of the leadscrew interrupts an optical sen- 
sor in the farthest stroke position and defines the home 
position. 

Since the analytical head assembly has to withstand the 
high system pressure of up to 400 Ijar, its design is very 
similar to the solvent pump head. The sapphire plunger 
and its seal are the same parts used in the HP 1050 solvent 
pumpsn When drawing up sainple, the plunger is forced 
by a spring to follow the leadscrew exactly without back- 
lashn The leadscrew and the plunger are decoupled by a 



ball, which transfers force. This design compensates for 
mechanical tolerances and increases the lifetime of the 
plunger seal. The overall resolution is 7 nl displacernent 
of the plunger with one step of the motor- 
Electronic Design 

In addition to the electronics found in all HP 1050 Series 
modules — power supply, microprocessor board, keyboard, 
and display — the autosampler contains module-specific 
electronics to support the injector hardware. Fig. 8 shows 
tbe autosampler electronic block diagram. The central 
motherboard, which interconnects all of the boards in the 
card cage, also has connectors for the electronic compo- 
nents located in the hardware area. 

The standard configuration has two additional boards. 
The first board controls the metering drive and the six-port 
switching valve, while the second board interfaces to the 
sampling unit. The first board also carries the injector'Spe-^ 
cific firmware on a small piggyback board. When the op- 
tional 100-vial tray is installed, a third board is added. The 
module-specific boards contain the stepper motor drivers 
and control logic to run the motors at speeds in the 1000- 
steps/second range while also monitoring and responding 
to the limit sensors. This design reduces the real-time 
hard ware- servicing requirements on the microprocessor 
and frees it from a lot of simple, periodic work. 

100- Vial Tray Integration 

The 100- vial sample tray (Fig. 9) was first introduced to 
increase the sample throughput of the HP 76 73 A Gas Chro- 
matograph injector. This tray was developed by HP's Avon- 
dale Division. Because of its modularity, we found the tray 
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to be an ideal way to Jnc:rease the sample capacity of the 
HP 1050 injector and provide temperature control of the 
vials. The opportunity to leverage an existing, available 
product instead of duplicating the design effort was on 
additional benefit. 

The tray offers storage, transportation, and temperature 
control of 100 sample vmls- The vials are placed in four 
removable quadrants. A circulating bath can be connected 
to fill and drain adapters at each quadrant. The transport 
mechanism is a small manipulator consisting of an arm 
and a gripper operating in cylindrical coordinates. The 
manipulator is mounted on top of the drive mechanism 
located in the center of the tray base. To transport a viah 
the arm moves radially and turns around the tray axis to 
place the gripper close to the selected vial position. The 
gripper moves vertically down and the vial is engaged at 
its neck. After it is raised, the vial can be placed anywhere 
within the arm's accessible area. 

The 100- vial tray is adapted to the HP 1050 autosampler 
by a compound design (Fig. 10). Sheet- metal parts used for 
the support ensure proper positioning and the required 
stability. A polyurethane foam part between the two sheet- 
metal parts spans the distance and adapts the tray's appear- 
ance to the HP 1050 industrial design. This support assem- 
bly is attached to the autosampler base with only four 




screws. The tray slides into the bracket to its defined posi- 
tion and is fixed with a spring-loaded clamp. The tray is 
controlled by an additonal printed circuit board in the 
card cage. 

If the 100-vial tray is installed, the user can specify not 
only interna] vials but also vials within the external tray 
area. In the internal tray, a transfer position is defined for 
vial exchange. For a sample injection from an external vial 
the arm picks up that vial and places it into the transfer 
position of the internal tray^ Then a standard injection is 
done using the vial in the transfer position. After injection^ 
the vial can be returned to the external tray or kept for 
additional injections. 

Automation CapabilHes 

The major use of an automatic injector with autosampler 
is to permit an LC system to run unattended* doing a series 
of analyses in a predefined way, say overnight or during 
the weekend. The HP 1050 autosampler offers two modes 
of automation. One mode, w^hlch is very easy to set up, 
can be used to analyze a set of samples under preset con- 
ditions. The user only has to specify the first vial, the last 
viaK and the number of injections per vial, Once started, 
the system analyzes the specified range automatically. 
There is no chance of changing analysis parameterSt but 
this models very useful fordoing a few injections rapidly. 

A more sophisticated way of automatiog an LC system 
is to use the full sequence capability of the autosampler. 
This mode allows programming of parameter changes and 
periodic Insertion of calibration injections. There are more 
parameters to be set up, but the versatility is high- The 
overall analysis sequence is built up by chaining parameter 
sets. A set alw^ays w^orks wuth the same analytical condi- 
tions. Chaining of up to nine sets is possible, and sets can 
be disabled to prevent their execution. A set contains the 
following parameters; 
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Fig. 1 1 shows an example of a set that includes periodic 
recalibratlons out of calibration vials (caiv) and results in 
the fol lowing series of injections (ci stands for calibration 
vial i and si stands for sarnple vial h The calibration mode 
is set to mujti.): 

start-cl 'Cl 'C2"C2-c3-c3-s4-s5-s6-s7-s8-s9-c1 -c1 -c2-c2-c3-c3-s10-s11- 
s1 2-s 1 3-S14-S1 5-cl -cr-c2-c2-c3-c3-s 1 6-s1 7-S1 8 s1 9's20-s21 -cl 'Cl - 
c2-c2 -g3-c3 -fi nished 



Fig. 10, HP 1050 Series support for the lOQ-viai tray. 
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Flexible, Precise Solvent Delivery for 
Liquid Chromatography 

The HP 1050 Series LC pump merges reliable, known 
technology with powerful control capabilities that 
compensate for solvent properties and physical side 
effects. A custom IC implements the motor and pump 
control functions. 

by Fred Strohmeier and Klaus Witl 



LIKE ALL HP 1050 SERIES MODULES, the pump mod- 
ule (Fig, 1) is a microprocessor-controlled stand- 
alone unit with full programmiog capabilities. It is 
compact in size and stackable with other HP 1050 Series 
modules to form a chromatographic system. 

The module can be used for analysis method develop- 
ment in research laboratories and for routine analysis in 
quality control. It can work either in HP's system environ- 
ment or together with instruments from other manufactur- 
ers. 

Parameter setting and programming are done using the 
functional keyboard on the front panel. A two-line display 
prompts the setting of parameters and provides feedhack 
by displaying parameter values. 

The instrument is available with tw^o different levels of 
complexity to meet the needs of customers" applications. 
At the entry level is the isocratic version ^ w'hich can only 
pump one liquid from a bottle. The more flexible quater- 
nary version is able to blend liquid from up to four different 
bottles in a selectable and time-programmable mixture. 

The main design goals for the pump were moderate cost 
and flow performance that does not limit the chromato- 
graphic applications. Because the range of chromatographic 



applications is wide, the flow rate of the liquid delivered 
to the column is adjustable over a wide dynamic range. 
The HP 1050 pump is designed for a factor of 10,000 be- 
tween the low^est and the highest flow rates. It delivers up 
to 10 ml/min in 1-ptl/min increments. 

Pump Design Options 

Although the flow rate of an LC solvent delivery pump 
should be adjustable, it is very important ihat once selected, 
the flow rate be kepi constant If the flow rate through the 
separation column fluctuates, variations in the retention 
times and ihe areas of the chromatographic peaks will 
occur. Since the peak areas are representative of the concen- 
trations of the separated sample components, fluctuations 
in the flow^ rate w^ould impair the accuracy and the repro- 
ducibility of quantitative measurements. The various de- 
tector types show different sensitivities to flow rate vari- 
ation. Commonly used detectors in liquid chromatography 
are absorption detectors, fluorescence detectors, elec- 
trochemical detectors^ and refractive index detectors. 

Some pumping systems, such as reciprocating pumps 
with single pistons, have inherent flow rate variations be- 
cause the piston delivers only during a portion of the pump 
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Fig. 1, isocratic HP 1050 Series LC pump module. 



Fig. 2. Stroke vQlume as a funchon of flow rate, st^ov^^ing the 
variable stroke capability of the HP 1050 pump. 
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cycle. Hydraulic capacitance Is used dovkustream from the 
pump to filter out most of the 100% pump ripple. To reduce 
the pump pulsation, it is possible to use a dual-piston 
pump ha\ing tw'o interconnected pump heads» eacli with 
a reciprocating piston. The pistons are driven by a cam 
and a camshaft with a predetermined phase difference so 
that one piston is delivering while the other is drawing, 
and the resulting flow rate is comparaUvely smooth. This 
type of pump is used in the HP 1050 pump module- 
Pumps using techniques other than reciprocating pistons 
(e.g., peristaltic, centrifugal, or gear pumps) are seldom 
used in high-performance liquid chromatography because 
the flow rate is also expected to be constant despite pressure 
variations of up to 400 bar. which is about 5800 psi. 

At the high pressures encountered in high-performance 
liquid chromatography, compressibility of the solvents be- 
comes noticeablep resulting in an additional source of flow 
pulsations. During each com:pression cycle of the pump* 
the piston has to move a certain distance to compress the 
liquid to its final delivery pressure before delivery of liquid 
starts. As a consequence^ pulsations in the outflow occur 
at the pumping frequency. These pulsating flow variations 
are particularly disturbing to reproducibility at low flow 
rates because the percent magnitude of the pulsations re- 
mains substantially constant over a wide range of flow rates 
while the amplitudes of the peaks in the chromatogram 
become smaller when the flow rate is reduced, particularly 
when smaller separation columns are used. 

The pulsations caused by the compressibility of the liq- 
uid are most often reduced by using specially designed 
cams that are contoured to produce the same amount of 
outflow of pressurized liquid at all points in each revolu- 
tion of the camshaft except for a short interval at the begin- 
ning of the expulsion stroke of a piston, where the piston 
moves with a higher speed. This precompression phase 



and the resulting positive outflow pulse compensate for 
the compressibility of the liquid. The effectiveness of the 
precompression phase is dependent on a variety'' of param- 
eters, including volume at the top center position of the 
piston, stroke volume, pressure in the pump* compressibil- 
ity of the liquid, stiffness of the pumping system, and clos- 
ing performance of the valves. Since not all of these param- 
eters can be precisely determined and especially since the 
liquid is in general unknown, a smaD residual pulsation 
in the outflow of the pump is to be expected. 

Dual-piston pumps can be classified into tw^o types; serial 
and parallel. In serial pumps the first and second piston 
chambers are connected in series. While the first piston is 
delivering liquid at twice the nominal flow rate, the second 
piston is refilled by drawing up some of the liquid from 
tlie first piston at the nominal flow rate. The net outflow, 
therefore, is just the set flow rate. During the intake phase 
of the first piston, the second piston delivers liquid to the 
system at the nominal flow^ rate and the first piston draws 
in liquid from the bottle at twice the nominal flow rate. 
Thus the second piston, running at half the speed of the 
first, alw^ays delivers the nominal outflow. This type of 
pump only needs one inlet valve and one outlet valve be- 
cause the second piston never pumps. It is only needed 
for damping the pump ripple. This type of pump is actually 
a single-piston pump with an active damping piston. 

In parallel pumps the two piston chambers are connected 
in parallel. Each piston chamber has two valves, with the 
inlet valves both connected to the liquid bottle and both 
outlets connected to the remainder of the system. The two 
pistons are operated ISO degrees out of phase, but at the 
same speed, so that one piston is always delivering liquid 
while the other is drawing to refill the pump chamber. This 
type of pump needs four valves, but the inlet flow is con- 
stant over the full pump cycle. 
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Fig. 3. Functfonai block diagram 
of the HP 1050 pump module. 
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The HP 1050 pump design is a serial type because it 
requires only half as many valves and therefore has lower 
cost and higher reliability. 

Design Philosophy 

There is a difference in design philosophy between the 
earlier HP 1090 pump design^ and the current HP 1050 
pump design. For the HP 1090, the approach was to use 
whatever hardw^are was needed to make the pump's perfor- 
mance independent of liquid properties and physical side 
effects. For the flP 1050, the approach is to use very simple 
and reliable hardware and to compensate for liquid prop- 
erties and major physical side effects in other ways, based 
on knowledge and understanding of liquid properties and 
characterization of side effects. 

The HP 1090 pump design splits the performance-deter- 
mining elements into a metering pump, which meters a 
precise flow rate against low pressure, and a booster pump, 
which pumps the metered flow against the high system 
pressure ► The HP 1050 pump consists only of two pistons 
and two valves driven by a servo motor by means of a gear 
and ball screw spindles. The tw^o pistons both meter the 
flow and generate high pressure, Because high pressure 
has a big impact on metering quality, compensation is re- 
quired to deliver a precise flow rate independent of solvent 
properties. For compensation purposes the user is required 
to enter a parameter for solvent compressibility. 

Integration Effects 

For quantitative chromatographic analysis, an integrator 
is used. An integrator is a reporting device that integrates 
the detector signal over time. Integration starts when a peak 
is detected and stops when the end of that peak is founds 
The integration result can be influenced by the pump's 
flow performance in several ways. The major influence is 
the flow rate itself. Because the detector signal is integrated 
over time, the same peak area may represent different com- 
ponent amounts. The correct relation is found by compari- 
son wuth standards. However, while this can compensate 
for the average value of the flow rate, the pump's flow 
ripple will still be reflected in the reproducibility of the 
area results. If the detector signal is flow or pressure sensi- 
tive, this will add to the flow variation. If the pump ripple 



is found on the detector's baseJine, the beginning and end 
of a peak may be misinterpreted and again the peak area 
w^itl change. Integration inherently suppresses all frequen- 
cies that are high relative to the peak width well enough 
not to disturb the results- Therefore, a high pump ripple 
frequency is desirable. However, this causes the valve clos- 
ing performance to have a greater influence on flow rate 
stability. With a fixed stroke and a wide flow rate ranging 
from 50 fj-Vnim to 10 ml/min, the pump frequency w^ill 
vary by the same factor — 200. A special variable- stroke 
f u net i o n of the HP 1050 pump reduces this ri p pie frequency 
range by a factor of five. The stroke is 100 ^1 at the highest 
flow rate and only 20 ^1 at the lower end [Fig. 2). This 
increases the ripple frequency^ especially at the lower flow 
rates, and thus decreases the influence of ripple on quan- 
titative results. 

Variations in the composition of the solvent mixture very 
strongly inflnence chromatographic results. The variable 
stroke volume leads to smaller liquid packages that can be 
better mixed in a given delay volume. No extra mixing is 
required. 

Pump Design 

The HP 1050 pump is a duaTpiston syringe type pump 
with an active inlet valve and a passive outlet valve (see 
Fig. 3). The two pistons are connected in series. The pri- 
mary piston defines the flow and the secondary piston is 
used for damping purposes only. Therefore, the second 
piston needs no valves^ 

Both pistons are driven by ball screw' spindles. These 
are connected to a gear system that drives the spindles 180 
degrees out of phase and the second piston at half the speed 
of the primary piston. This requires a drive motor that is 
able to reverse rotation within a very short time. The digital 
servo system has a high bandwidth of about 200 Hz and 
the motor shaft can be positioned with a resolution as low 
as one quarter of a degree. The result is a very linear drive 
for the piston displacement with the high reliability of a 
ball bearing. 

The liquid is drawn in through the opened active inlet 
valve into the primary pump head when the primary piston 
Ls moved dow^n. In the isocratic version the liquid comes 
directly from the solvent reservoir, while in the optional 
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quaternary- version the muUichannel gradient valve 
(MGGV) selects one of four solvent reservoirs at a time. 
When the priman^ piston reaches the end of the selected 
stroke, the direction of movement is reversed, the active 
inlet valve is closed, and the liquid Is pressed through the 
outlet valve towards the secondary' punap head. There are 
no valves at the secondary' pump head hecause it is for 
damping purposes only. On the way to the chromato- 
graphic system the liquid passes the hydraulic damper^ 
which has the additional function of meBsunng the system 
pressure. 

The primary pis Ion runs at a displacement speed that is 
twice the flow rate because it only draws in liquid during 
half of the pump cycle and delivers liquid during the other 
half of that cycle. While the primary^ piston is delivering 
twice the flow rate, the secondar>^ piston, running back- 
wards, draws off half of that volume. Thus the remaining 
outflow is the nominal flow rate. During the intake phase 
of the primary piston, the secondary piston displaces liq- 
uid, keeping up the flow rate until the first piston chamber 
is filled again. 

The flow rate quality of such a pump relies on the switch- 
ing characteristics of the valves. Therefore, an active inlet 
valve was chosen, A special bipolar drive 3 1 lows this valve 
to operate in milliseconds. The pump control chip switches 
the valve with a delay as low as one microsecond. 

For the quaternar^^ pump, in which two or more solvents 
can be mixed in varying proportions to form gradients ^ the 
specially designed flowstream liirough the pump head al- 
lows very precise gradient formation because the flow di- 
rection of i:he proportioned solvent volumes does not 
change on the way to the system. The solvent reaches the 
pump chamber near the piston seal and leaves at the top 
of the pump head. Very good mixing of multiple solvents 
is achieved by the double active mixing characteristics of 
the two pistons in series. During the intake phase the sol- 
vent flows through the ring gap around the first piston. 
This forms turbulence at the top of the pistan that mixes 
the solvent in the right order, the old compositiQti at the 
top and the new composition at the bottom. This order 
results in smooth transitions during programmed gradients. 
During the delivery phase the first piston delivers the pre- 
mixed liquid in the proper order while the second piston 
does the mixing. The ring gap and turbulence behave in 
the same way as for the first piston, but the main mixing 
mechanism is that the outflow half of the liquid passes the 
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Fig. 5. Typical plot of motor position as a function of time. 




half that is withdrawn by the second piston. This works 
almost like integrating a noise signal over exactly one 
period, Because this mixing is inherently s\Tichronized 
vtTth the proportionijig of the solvent volumes » no addi- 
tional mixing device is needed to reach a composition sta- 
bility of ±0.25%, even though the composition is formed 
by low-pressure proportioning. 

Drive Motor Position Control 

The HP 1050 pump is driven by a position-controlled 
motor. The motor, encoder, and digital servo technique are 
almost the same as in the HP 1090 pump,^ but the pump 
drive control is different. Early protot^^pes showed that it 
is essential for the flow performance and especially for the 
gradient composition that the motor control system have 
fast response and fine time resolution. Following the design 
philosophy, the influence of solvent properties is compen- 
sated by control means. Where the HP 1090 design only 
required a constant step frequency, the HP 1050 also needs 
a precise upper dead volume and a variable but reproduc- 
ible stroke volume. The increased flow range of up to 10 
mhmin adds a factor of two in dynamic range , so the control 
response is required to be faster than 40 ^s. 

The low pressure gradient requires that the solvent selec- 
tion valve be controlled so that the volumes of the various 
pod ions of solvent are reproducible. Because of the com- 
pensation, the flow rate is multiplied by correction factors. 
Therefore, with fixed valve timing a given portion's volume 
will change. With position dependent valve switching, the 
portion's volume is independent of the speed of the motor. 
25-nl reproducibility in volume requires 80-^s reaction 
time in position. The valves are not switched that fast 
{switching time is 1 to 2 ms); however, the reproducibility 
of the valve switching points is better than 100 ^s. 



Compression 
Volume 



Solvent, ^ 




Fig, 6. (niluence of solvent compre^sfbitity and elasticity. 
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The pump control system performs the following func- 
tions: 

■ Servo position control for the motor 

m Step frequency generation [IS-bit and 1-Hz resolution) 

■ Range detection and direction control at the ends of the 
stroke 

■ Position jump function to a selectable compensation po- 
sition at the beginning of the compression phase 

■ Synchronized control of the active inlet vaJve 

■ Position dependent generation of valve timing signals 

■ Bidirectional bus interface to the micro processor. 

All these functions are implemented in a single applica- 
tion-specific integrated circuit [ASIC, see box, page 30). 
All functions influencing flow reproducibility specifica- 
tions are incorporated. The ASIC can control the pump 
with a constant set of parameters independent of the micro- 
processor. Fig. 4 is a simplified block diagram of the ASIC 
control chip. 

The set of parameters required by the control chip con- 
sists of the motor speed, the distance between the zero 
position and the stroke end, the compensation position to 
which the position is set when the compression phase 
starts, and up to three different position marks for the gra- 
dient control. Fig. 5 shows a typical plot of motor position 
as a function of time. 

Parameter changes input through the user interface or 
by run programming become active with the next pump 
cycle. The microprocessor does not influence the stability 
of flow^ and therefore it is free to handle the user interface, 
the parameter .set, and the compensation calculations that 
are required to make the outflow independent of the back 
pressure. New sets of parameters are loaded to the chip in 
synchronism with the pump cycle. When the pump starts 
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the intake cycle, the new step frequency, stroke length, and 
compensation position are written to the chip. When the 
pump starts delivery, the position marks for gradient forma- 
tion are updated. This ensures that the new data is available 
well ahead of the time when it is needed. 

Solvent Properties and Physical Effects 

With regard to flow accuracy, the dual-piston serial type 
pump can be considered a single-piston pump with active 
damping [by the second piston, which has no valves). The 
second piston only infloences the short-term flow stability. 
The two major effects are ripple and roll-off. 

As in single-piston pumps, the internal pump head vol- 
ume has to he compressed to system pressure before any 
liquid is delivered to the system. This compression volume 
(see Fig. 6) can be calculated as the sum of the elasticity 
of the pump head and the total volume in the pump 
chamber multiplied by the solvent compressibility, multi- 
plied by the system pressure. During the time that the pis- 
ton needs to travel this distance, the first-order damping 
characteristic of the system reduces the pressure, which 
changes the flow rate. This flow variance synchronized to 
the piston's movement is known as the flow ripple. The 
second piston can help reduce the ripple, as show^n in Fig. 
6, However, some ripple remains, its magnitude deter- 
mined by the compression volume and the response of the 
first-order damping characteristic of the hydraulic system. 

Roll-off is the reduction of outflow dependent on system 
back pressure. After the compression phase and during the 
remainder of the delivery phase the pump delivers com- 
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Fig. 7. Ripp!e compensation with compression jump. 
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pressed liquid, which expands on its way through the col- 
uino. Because of the expansion, the flow delivered is higher 
than the volume displacement of the piston (see the com- 
pressed stroke volume in Fig. 6). At the end of the stroke 
the piston changes direction and the intake phase starts. 
Because of the pump head's dead volume, the liquid is 
decompressed, which means that its volume expands, and 
the elasticity of the pump chamber is released. During this 
time no new liquid is drawn in. Liquid that is not drawn 
in cannot be delivered. Therefore, in the long term the 
outflow is reduced by 

r ~ (Voi*c + elasticity) x pressure x pump frequency. 

where V^t is the dead volume of the pump and k is the 
solvent compressibility. The liquid part of this effect varies 
with the solvent used while the elasticity is only dependent 
on the mechanical construction. 

To reduce the magnitude of this effect the pump's inter- 
nal dead volume must be minimized. In the HP 1050 pump 
design, this volume is as low as 40 ^L This is achieved 
using a special absolute referencing method [explained 
later), Using isopropanol as a liquid, the mean compressi- 
bility is 100xlO"*'/bar and the decompression volume is 
only 4 nl/bar. With such a low solvent effect, the physical 
elasticity is no longer negligible. Because of the plastic 
material used for sealing, the elasticity has a value of about 
8 nUhar. 

To compensate for these two negative effects, the pump- 
specific ASIC chip supports a special function. Instead of 
moving the piston back and forth with constant speed, a 
Dirac impulse function having an area equal to the com- 
pression volume is added to the speed function (see Fig. 
7). Theoretically, this causes a position jump, a controlled 
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movement within zero time. In operation, the mechanics 
need only 40 milliseconds maximum to perform this action. 

The distance between the stroke end and the compensa- 
tion position is calculated by the microprocessor every 
pump cycle. The servo system causes the motor to perform 
this jump using its maximum power. The resolution is 13.5 
nl. which allows precise compensation for any stroke, pres* 
sure* and solvent. 

The function just described compensates for compres- 
sion volume. To compensate for compressed stroke vol- 
ume, a new running speed is set. The new speed is the 
original speed reduced by the compression factor, so that 
the flow rate of the decompressed liquid at the detector 
remains constant, independent of system pressure [see Fig. 
81. This compensated flow is set during the intake phase 
and is activated when the next delivery phase starts (after 
performing the compensation jump). These two chip func- 
tions reduce the pump's rippie to a very narrow and sharp 
pressure peak that is small and fast enough to have almost 
no influence on the chromatographic results. 

To compensate for roll-off, a new function of the HP 
1050 pump — ^variable stroke volume — is used. The roll-off 
problem is that, because of the decompression phase, the 
pump cannot draw in as much liquid as the stroke length 
would indicate. The intake stroke is effectively shortened, 
and therefore, to compensate, the stroke has to be 
lengthened by the same amount. The variable stroke feature 
makes it easy to set the pump control chip to a stroke value 
thai is the sum of ih^ nominal stroke plus the decompres- 
sion volume (see Fig. 9). During the time it takes to draw 
in this added volume, the second piston keeps the flow 
constant. When the ripple compensation jump is executed, 
the decompression volume is compressed again to the sys- 
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Fig. 9. Inftuence of lengthened stroke on intake volume. 



Fig. 10. Determsnatfon of an absolute reference position. 
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Pump Control Chip 



The design, mechanfcaE construction, and compensation func- 
tions of the HP 1050 pump module require a high-performance 
motor and control system with high resolution, dynamic range, 
and power. 

Dynamic performance can be divided into two parts. One is 
the abi[ity to accelerate and decelerate, which is mainly deter- 
mined by ttie torque and internal mejiia of the motor, The other 
is the useful outpuf torque as a funclion of frequency. Dc motors 
have an advantage in this area, while steppers, especialty without 
feedback, are weak here. Steppers tend to show resonances at 
various frequencies, and reversing the current in their inductive 
windings with a limited voltage takes time. The HP 1050 pump 
would require a stepper motor running at a 125"kH2 step fre- 
quency with more than 1000 steps per revolution. Even with no 
load and a long rampup time, this is drfficult to achieve. Standard 
dc motors are not allowed in analytical laboratory instrumentation 
because of sparks and the risk of expfosEon. Stepper motors 
generally have good resoJution or dynamic range but not both, 
and are difficult to use with variable loads. 

To meet the requirements it was decided to use a position 
control servo system of a type used in many HP applications 
inctuding robotics, plotters, and the metering pump in the HP 
1090 HPLC system, predecessor of the HP 1050 Senes.'' For the 
high-dynamic-range requirements, it was found that a variable- 
reluctance (VR) motor, which is driven with control circuitry like 
a brushless dc motor, provides the best performance. 

The HP 1050 pump design requires high power to pump liquid 
against high pressure. The running speed is seiectabie from 
to 10 ml./min with a resolution of 1 ftl/min. This operating dynamic 
range is increased by the compensation caicuiations, so the 
Internal resolution is 0.4 ptl/min for a 1-Hz stepping frequency 
This implies a maximum stepping frequency under a 200-bar 
toad of 25 kHz, or 12,5 kHz with a 400-bar load. The VR motor 
meets these requirements. It also has enough power to acceler- 
ate the pump from zero speed and jump 1 000 steps within 40 ms. 

The servo system is ail digital. This makes it easy to integrate 
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into an ASIC {application-specific integrated circuit) chip, which 
saves cost and increases reliability. There were servo chips avail- 
able, including the position control chip designed for the HP 

1090 metenng pump, but these would have needed companion 
microprocessors running with at least a 1-kH2 interfupt rate to 
achieve the pumping performance. Therefore, it was decided to 
design a new standard-cell chjp that incorporates all the required 
control functions to operate the pump hardware. An extern ai 
microprocessor is only needed for parameter setting and the 
compensation calculations with a timing requirement of 200 ms. 
These can be done by the system's main processor and no extra 
chip IS required. 

Chip Design 

Our expenence with standard cell design was very helpful. 
We worked together with HP's Cupertino Integrated Circuits 
Divjsion, and the tirsi design was functional, No changes were 
needed When we started the chip design, HP technology had 
just changed from CMOS-H to CMOS40. and the design station 
frorn HP EGS to HP EDS. S>ince all our experience was on the 
EGS system and the old HP 1090 chip design was to be a third 
of the new HP 1 050 chip, it was decided to design for CMOS-H 
on EGS and convert the design to CMOS40, 

Fig 1 shows a functional block diagram of the pump cofrtrdi 
chip. The heart of the chip is a 14-bit position servo system that 
is designed to dnve a special VR motor developed by HP 
Laboratories in 1964 and manufactured by Warner. The buiJt-in 
commutator is fixed for a three-phase motor and an encoder that 
has a factor- of-60 higher step count than the motor steps (for 
example, a 3-phase VR motor with 24 steps/rev and a 360-slit 
encoder with 1440 steps/rev) 

The setpoint position counter can be accessed directly via the 
interface bus by writing to it through the compensation position 
register in position control mode. The motor will perform a jump 
to the wMtten position. 

The chip contains circuitry that makes the servo frequency 
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conlrollabie, so the motor speed can be the contfdted parameter 
rather than pos?t)on, This ts Hie main mode of operation when 
driving a pump. The motor speed is settadle m a wide IS-blt 
range with ^-Hz fesolution A control signal appNed to one of the 
chip's pins causes the frequency range to be scaled up by a 
factor of 16. The motor direction is another control bit, so the 
running speed is selectable over a lull ifi-bit range (±32.767 
counts) 

Two position marKers can be set with 14- bit range. One is the 
stroke end and the other is the compensation position When the 
motor's setpoint position reaches the stroke end> the motor direc- 
tion is reversed At the zero position, the direction is again re- 
versed, giving the back-and-forth pumping action. When the 
compensation position is sel to a number smaller than the stroke 
end. the motor will jump to that position before it starts moving 
backwards This function is used for flow compensation 

Three more registers allow the setting of position marks for the 
motor When a mark is reached the chip sends out a pulse. 



These pulses are used in the pump to switch the gradient mixing 
valves synchfonously with the pump s sucking action 

Sonne control bits round out the functions of the chip so that 
ft can be used for universal motion control specialized for the 
particular motor used for the pump The chip includes all tunc- 
tions needed to drive the HP 1050 pump Once the parameters 
are set, the chip will ensure stable flow for days or years without 
any further microprocessor action. Thus the pumping peffof- 
mance is totally independent of processor load or interrupt prior- 
(ty 
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tern pressure. The intake volume, therefore, is exactly the 
nominal. The pump frequency remains constant — there is 
only a slight phase shift of the intake phase. Since flow 
rate is vohime times frequency^ it is also exactly the nom- 
inal, and there is no roll-off. 

Absolute Referencing 

During normal operation the drive system of the pnmp 
works in an absolute ptisilion crjntrol mode, F*"or this mode, 
it is necessary to know at least one absolute position refer- 
ence. Former designs used light sw itches or magnetic sen- 
sors for the absolute feedback. For the HP lD5f) pump, price 
and reliability considerations led to a new solution. 

The absolute position reference has a direct influence 
on the primary piston's dead volume, w^hich leads to flow 
disturbances like the roll-off and ripple explained earlier. 
I'he Hl^ 1050 pump is designed to compensate for these 
dis!iirl),iiu:es, hut il i.s required I ha I the dead volume be 
k[R)wn, constant, and as low as possible. The tolerances 
of regular position sensors would require complex adjust- 
ments, because the primary pi.ston's top dead center is 
designed to be only 77 ;xni aivay from the lop of the punqj 
head. A reference signal is available from the motor posi- 
tion encoder, but it occurs every revrdution, 6 or 7 times 
during the stroke (see INDEX signal in Fig, 10]. Because it 
occurs more than once during the stroke, this index signal 
cannot be used directly. It is necessary to find the first 
occurrence. Therefore, a special algorithm is required for 
absolute referencing. 

For this algorithm, special functions are implemented in 
the motor controller chip. The motor current can be read, 
the encoder index signal is visible to the microprocessort 
and in a certain position range the setpoint position counter 
can be loaded with a predefined offset value. During assem- 
bly, the pump mechanical gear system is adjusted so that 
the first encoder index signal occurs within about 160 to 
66Q encoder steps away from top dead center. To find the 
absolute reference position, the primary piston is moved 
slowly towards the pump head while the microprocessor 
monitors the motor fjurrent. When the motor current, an 
B-bit digital wT>rd, increases in value, the piston is at top 
dead center. The piston is then pulled back and the micro- 



processor measures the exact distance moved until the first 
index pulse occurs. This distance is used to calculate the 
numeric value to w^hich the setpoint position counter must 
be loaded each lime the piston reaches the index pulse 
that occurs inside the sensing range (see Fig. 10). Sub- 
sequently, the servo always reverses direction when the 
setpoint counter reaches a count of zero. Thus, for exam.pie, 
when the first index pulse is found 246 steps away from 
the top, the setpoint counter is loaded wnth 200 to ensure 




Fig, 11. The quaternary HP 1050 pufnp module can mix up 
to four Biolvents to form gradients. 
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that the piston reverses direction exactly 46 steps before 
top dead center. The referencing algorithm is accurate 
within four steps, which is 53 nl in dead volume or 6.7 
iXTU in piston position- 
When the pump head is changed to one with different 
tolerances, it is not necessary to readjust ihe position sen- 
sor. The referencing algorithm aligns itself in a wide range 
of 0.8 mm. 

This initialization [computation of the numeric value) 
is performed whenever the pump motor is started. The 
position referencing (loading of the numeric value into the 
setpoint counter] is performed every time the piston ap- 
proaches the top. Therefore, disturbances on the encoder 
lines are not accumulated, and long- terra operation is not 
d problem. 

Gradient Formation 

Most chmmatographtc analysis requires solvent blend- 
ing. At least during method optimization, it is useful to 
have a free choice of solvent composition. Some applica- 
tions require the solvent composition to be modified during 
the analysis. This mode is called gradient programming. 

The HP 1050 pump design is a low-pressure gradient 
system, which means that the solvent mixture is formed 
ahead of the pumping apparatus. The mixture is formed 
by sequential proportioning of the different liquids during 
the intake phase of the pump. Because some liquid combi- 
nations as a mixture can solute less gas I ban the separate 
liquids, the gas content has to be lowered below the satura- 
tion limit. This is done by purging the solvents with helium. 
It has been foimd that helium is able to replace the gas in 
a liquid such that the final amount of helium in the liquid 
is much low^er than the original amount of gas. Some detec- 
tion systems do not allow oxygen in the mobile phase but 
helium is well accepted. The HP 1050 quaternary pump 
(Fig, 11) is shipped with a solvent preparation cabinet that 




Solvent frrflow 



Fig. 13. Position dependeni soivent proportioning. 

includes solvent battles, bottle caps with solvent filters, 
and a set of helium fkm^ control valves. As an option, the 
solvent cabinet can have a manual injection valve, and 
there is a column compartment that holds the analytical 
column and a leak tray to collect leaking solvent. 

A dual-piston serial type pump draws liquid during only 
half of the pump cycle. This increases the switching re- 
quirements for the proportioning valve. The number of 
different portions also affects these requirements because, 
as the number of portions increases, the probability that 
some of the percentages are ]ow also increases. At a flow 
rate of 10 ml/min and a stroke of 100 jLtl, the switch-on 
time for one channel is as low as three milliseconds per 
percent in composition. To achieve the specified ±0.25% 
absolute composition precision, the valve is required to 
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switch within 1 ms. 

To achieve such fast switching with magnetic solenoids* 
the overdrive technique is used- For on times up to 10 ms, 
the valve is driven by a voltage five times nominal. For 
longer on times, the voltage supply is chopped after 10 ms 
at a rate of 25 kHz and the duty c^xie is 20%. When a 
changeover from one channel to the next occurs, at first 
all channels are switched off to avoid crossfloTA^ hetw'een 
the different solvent containers. This *'all channels off" 
situation allows all four solenoid drivers to be combijied 
so that only five power transistors are needed (see Fig. 12). 

If there is a small solvent proportion right at the begin- 
ning of an intake phase or right at the end, there is a chance 
that the proportion will be influenced by the switching of 
the inlet valve or by the decompression phase, which pvG- 
vents the drawing of solvent for a certain time. This effect 
can be large enough that no soh^ent will be drawm for that 
portion, thereby spoiling the composition accuracy. To pre- 
vent this, a function called the primary channel is im- 
plemented. The primary channel is the one that is opened 
at the beginning of the intake stroke, and therefore is the 
one that is influenced by the pressure dependent decom- 
pression phase. It is selected by an automatic function or 
by the user. This primary portion is split, and Is drawn in 
partly at the beginning and partly at the end of the intake 
stroke (see Fig. 13]. Up to two smaller portions can follow 
in sequence between the two parLs of the primary portion. 
Because the same channel is opened both rimes the inlet 
valve is switched, the influence on composition is automat- 
ically compensated. Any change in the decompression vol- 
ume because of changing pressure reduces or enlarges the 
first channel's porrion. By the compensation calculations 
described earlier, the stroke is adapted to the decompres- 
sion volume, and therefore ihe last channer.«^ portion is 
enlarged or reduced correspondingly^ Since the first chan- 
nel and the last are the same, the effects compensate. The 
same occurs when the valves have a delay between the 
electrical signal and the mechanical switching action. This 
changes the phase between the proportioning and the pump 
cycle, but all portions remain the same. The user is ex- 
pected either to use the automatic function or to decide 
which channel is primary (first). 

One channel is always open, even when the pump is in 
the delivery phase. Thh ensures that the pressure between 
the gradient valve and the inlet valve does not rise even 
when the inlet valve has hackflow because of dirt or a 
malfuncrion. 
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Diagnostics and Monitoring 

The HP 1050 pump is designed on the basis of a complete 
understanding of the effects and parameters that influence 
the performance of a high-pressure pump system. The sys- 
tem internally handles all the values that influence the 
performance bb single and knowm parameters. These pa- 
rameters are given as digital values to a pump control cir- 
cuit that forces the precision pump mechanism to produce 
the expected solvent flow accurately. The simple structure 
of the pump mechanism and the open design of the pump 
control logic allows the microprocessor to compare expected 
events with the real situation for a variety of parameters 
and thus generate diagnostic information that is of real 
value to the user. 

Faults are detected either during self -tests or w^hen un- 
wanted events occur. The goals are to find faulty compo- 
nents that need to be replaced, or to detect events that for 
safety reasons require that the system be switched off before 
it destroys others or itself. In nearly all cases, when a fault 
is detected the system will stop normal operation and in- 
form the user that some action or service is needed* The 
operating and service manual contains suggestions for 
further diagnostic actions to point out the faulty element. 

The system can detect 24 different error states, some of 
which may indicate faults. In all cases, detection of one of 
these states places the instrument in an error state. In some 
cases, a predefined error method will be called for and 
executed. The system will print the reason for entering the 
error state on the display to inform the user. The error 
conditions can be placed in three categories: 

■ Start-up errors* soch as KAM test failed 

s» Initialization errors, such as pump reference lost 

■ Operating errors, such as pressure exceeds 420 bar. 
There are always some effects that cause the performance 

of a pump system to become wor.se with time, eventually 
becoming insufficient for the application. If the instrument 
is able to detect these changes early enough and inform 
the user, the user will be able to plan for corrective action 
or repair. The HP 1050 pump has a number of continuous 
monitoring functions that watch for such effects. The re- 
sults of these monitoring functions do not have a direct 
influence on the pump's operation. They will not cause 
the pump to switch off. They are placed in the internal 
memory "logbook'' and can be accessed by the user, who 
can initiate further actions . There are f ou r d iagnos i s I evel s : 

■ Level 0: On-line monitoring is switched off. 

■ Level 1: On-line monitoring results are wTitten to the 
logbook and can be called for using the STATUS key. No 
further actions are taken by the instrument. 
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Fig* 14. >^ typical pressure trace and its reiation to the pump 
cycle (right side time scale expanded). 



Fig. 15, Gas bubble detection using ripple informBtlon, 
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■ Level 2: On-line monitonng results are written to the 
logbook and can be called for using the STATUS key. The 
system goes to the not ready state. The N'READY LED is 
lit and the N'READY control line of the remote control 
bus is pulled low to prevent further injections. 

■ Level 3; For use only by production or service person- 
nel, mainly to measure the available stroke to check the 
pump drive adjustment. 

On-Line Pressure Monitoring 

In normal operation, the system pressure is continuously 
monitored and displayed in selectable pressure units (MPa, 
bar, or psi). There is an analog output at the rear of the 
instrument for plotting the pressure on an integrator, which 
can be the same one that is used to monitor the detector 
output. 

A major reason for monitoring the pressure is safety. The 
user can type in upper and lower limits for the pressure. 
The upper limit is used to protect the column against too 
high a pressure, while the lower limit is used to detect a 
dramatic leak in the system or that the solvent reservoir is 
empty and the pump is drawing air. 

This absolute pressure monitoring does not require pre- 
cise time resolution, How^ever, short-term pressure vari- 
ations are also monitored for such purposes as gas bubble 
detection and flow symmetry analysis. So as not to overload 
the microprocessor with complex calculations at a high 
speedy a specially designed an a log- to- digital converter 
(ADC) is built into the pump. Called the relative ADC, it 
delivers a data word proportional to the relative difference 
of tlie input voltage and a reference. Absolute values are 
calculated from this relative data about once per second, 
while the relative mformation is available without calcula- 
tion about every 10 ms. 

Ripple Measurement and Gas Bubble Detection 

In a normal HPLC system, the hydraulic resistance is 
linear, and therefore the pressure signal is a good tool for 
monitoring the flow stability. However, the absolute value 
of the resistance depends on solvent properties and temper- 
ature, as well as variations in the flow path, so the absolute 
value of the pressure caiuiot he used. The relative informa- 
tion, on the other hand, is very useful for monitoring func- 
tions. 

Fig, 14 show^s a typical plot of HP 1050 pump pressure. 
Most of the short-term variation is synchronous wnth the 
pumping action. This peak-to- peak variation is the ripple. 

In the HP 1050 pump, ripple compensation calls for a 
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high-speed precompression phase right after the primary 
piston begins to deliver. This phase is less than 35 ms in 
duration. Because this action will not aivt^ays perfectly com- 
pensate for the solvent's compressibility, the system pres- 
sure after the compression phase will vary. The HP 1050 
pump exhibits a positive ripple if the pressure after the 
compression phase is higher than before and a negative 
value otherwise. A peak-to -peak value normally is positive 
only, but the extra sign indicates whether the pump is 
overcompen sated or undercompensated. 

With a gas bubble in the primary cylinder, the compres- 
sibility of the vohime will increase dramatically [see Fig. 
15). Therefore, the mismatch between the ripple compen- 
sation and the actual ripple can give information about the 
gas content. To detect gas hubbies, (be last pressure value 
before the pump changes to the delivery phase is stored. 
This value is compared with a pressure value measured 
about 40 ms after the direction change. Because all pressure 
values are available as percentages of the mean value, the 
ripple can be calculated as simply the difference between 
these two values. If the ripple is greater than a limit that 
depends on the compressibility, a gas bubble is suspected 
and a message is stored in the logbook. 

If the bubble is an isolated phenomenon, that is, if gas 
is not entering the pump head continuously, then after 
some time the cylinder will be filled completely with sol- 
vent and a message will be entered into tlie logbook indi- 
cating that the gas problem has been solved. 

The secondary ripple, that is, the pressure drop when 
the second piston starts delivery, is used to check the clos- 
ing function of the outlet valve. This ripple is normally 
well below 1%. If the valve is closed by backll owing liquid, 
this secondary ripple is increased, as shown in Fig. 16, and 
a message is generated. 

Flow Symmetry Analysis 

Continuous backilow^ through the outlet valve show^s a 
different pressure shape and is detected using flow sym- 
metry analysis. Flow symmetry analysis is a monitor 1 unc- 
tion that derives tlie end value of the pressure under the 
assumption that each piston will deliver the same flow 
forever. Essentially, this is the value the pressure ap- 
proaches as^Tnptotically during the time a given piston is 
delivering. The values are calculated for each piston sepa- 




Fig, 1 6. improper closing of the outlei vafve leads to second- 
ary ripple. 



Fig, 17. An example of flow asymmetry caused by a leaky 
first piston. 
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points are selected so that three equally spaced points are 
spread over each half pump cycle. This avoids the need to 
calculate an exponential function of an unknown first* 
order damping system (see Fig, 18), 

Summary 

The HP 1050 pump module is a very simple but precise 
mechanism driven by a high-dynamic -range servo drive. 
The design merges reliable known technology with power- 
ful new control capabilities, hn active inlet valve, custom 
IC technolog}^ for the position servo, and a complex control 
algorithm running on an MC68008 microprocessor result 
in a pump that performs well, is easy to operate and main- 
tain, and offers automation features to address a variety of 
applications. 



Fig. 1 8. Calculation of the pressure asymptote without know- 
ing the damping function. 

rately and are called as\Tnptote #1 and asymptote #2. 
AsjTnptote #1 is calculated from the pressure trace of the 
primary piston and asymptote #2 from the pressurR trace 
of the secondary piston. 

An optimal pump system will show pressure differences 
between the two phases of the pump cycle if the mean 
values or the final values of each cycle are compared. This 
is because only the primary piston compresses the solvent 
to system pressure. However, the asymptotes of both phases 
should be identical under stable conditions. If these values 
differ by more than 1% (Fig. 17], a logbook message is 
generated indicating either that the primary piston leaks 
or that there is outlet valve backflow, depending on which 
as^^mptote is greater. Trends, such as pressure slopes, are 
fiUered out using the values from the last cycle. 

For flow symmetry analysis, the microprocessor has to 
calculate the asymptote of an exponential function twice 
per pump cycle. To reduce the calculation effort, the data 
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A New Generation of LC Absorbance 
Detectors 

Two absorbance detectors are available for the HP 1050 
Series modular LC system: a high-sensitivity programmable 
scanning detector and a high-speed, multiple wavelength 
diode array detector, 

by Axel Wiese, Konrad Teitz, Volker Brombacher, Giinter Hoschefe, and Hubert Kuderer 



THE MOST IMPORTANT DETECTION PRINCIPLE in 
liquid cfiromatograpliy (LC] Is absorbance detection 
in die ultraviolet and visible wavelength ranges. 
Sample molecules with chromophore groups absorb light 
and are excited into higher electronic energy levels. The 
observed spectrum, a plot of light absorbed as a function 
of wavelength, is characteristic for any species and is there- 
fore helpful in identifying compounds previonsly sepa- 
rated in a liquid chromatography column. 

There are two types of LC absorbance detectors, each 
having its own special features and characteristics. The 
first is the forward optics detector. White light is separated 
by a wavelength dispersive element — typically a grating — 
and one selected wavelength passes through the sample in 
a flow^ cell of an LC system ^ This type of detector is set to 
one wavelength at a time. Spectra can only be acquired by 
stopping the pump flow and turning the grating from one 
position to the next to change the w^avelength in the cell. 
In the early 1980s, HP introduced the reverse optics detec- 
tor. White light first passes through the flow cell, where it 
is attenuated at wavelengths characteristic of the sample 
molecules. It is then separated and directed by a grating 
towards a diode array. Each diode detects light in a very 
narrow wavelength range, and there are enough diodes that 
all wavelengths of interest are detected siinultaneously. 
Originally used for pure research, diode array techniques 
are beginning to be used for routine analysis in quality 
control laboratories. An invention of the 1970s, the holo- 
graphically fabricated concave grating, can resolve the 
wavelength range on a nearly linear focal curve. This kind 
of self-scanning photodiode-array detector can produce 
dozens of spectra in a second, on-line- With a microcom- 
puter Itandling the resulting data stream, n speed iinattbin- 
able with forward optics detectors is achieved In the mea- 
surement of separated compounds. For the HP 1050 Series 
Liquid Chroma tographs, the forward optics technique is 
now driven to its highest sensitivity so far wuth the HP 
79853A Variable Wavelength Detector (VWD). while the 
HP 79854A Multiple Wavelength Detector (MWD), the re- 
verse optics solution, features a wide range of spectral ca- 
pabilities. 

Theoretical Background 

The basic equation for absorbance spectrometry is the 
Lambert- Beer law: 



A[X] = €[X)CD = log 



Io(Xl 
1(X) 



where A[X) = absorbance in absorbance units (AU) as a 
function of wavelength 
€ (X) = extinction or molar absorption coefficient 
as a function of wavel ength 
C = molar solute concentration 
D = path length (mm) 
Iq = incident photon flux 
I = transmitted photon flux. 

In terms of the photocurrents of the array diodes and the 
associated preamplifier circuitry, the above equation is: 



A(X) = log 



hjg 



Iref + Il' +I2' +13' 



sample 



+ II + I2 + I3 



w^here l^i 






= photocurrent reference signal 
Isamjiio = photocurrent sample signal 
Ii ' ^h ^ photocurrents produced by stray light 
Iz'J2 = additional offset currents produced by 

the signal electronics 
I3M3 - dark currents caused by the photodiodes. 
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Fig. 1. Output Signal noise of a diode array detector as a 
function of photocurrer^t. 
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The absorbance signal can be corrected for offset and 
dark currents simply by measojing these currents during 
an analysis. Stray light is the main factor limiting the detec- 
tor's linearity. Stray light is an intrinsic property of 
wavelength dispersi\^e elements, which means that gratings 
of the highest quality are absolutely necessaiy . In the HP 
79854A MWD, stray light is less than 1/1000 of the sample 
light, resulting in a linearity error of less than 1% up to 
1.5 AU. 

Flow Cell Trade-Offs 

According to the Lambert-Beer law, a longer path length 
gives a correspondingly higher signal. However, longer 
path lengths result in larger volumes, increasing the disper- 
sion of the separated peaks. Reducing the volume with a 
long path length reduces the light throughput, correspond- 
ing to a relatively higher (absorbance] signal leveh but at 
a higher noise leveL A further constraint comes from an 
"Iron Rule" of chromatography, which says that no more 
than 10% of the original resolution musi be lost in the 
detection system. This means that the volume of the flow 
cell must be; 






where V^ = retention volume 

N - number of theoretical plates (a column 
parameter]. 
For these reasons, all absorbance detector designs are 
trade-offs between path length, cell volume, and total 
photon flux, which is controlled by the element with the 
smallest light conductivity, the flow celL 

Signal-to-Noise Ratio 

In tiddiljnn In llift path length of the flow cell and the 
dispi^rsion of the el uted peak, signal-to-noise ratio is a limit- 
ing factor in detector performance. 

In modeling the noise contributions in a photometric 
absorbance detect or, three types of noise need to be con- 
sidered: Schottky noise, independent noise, and propor- 
tiqnal noise. There is also a relationship between photomet- 
rie noise (noise associated with the photometric signal) 
and output signal noise: 



Ontput Signal 
Noise (AU) 



Photometric Noise 
2,3 X (Photometric Signal) 



Schottky Noise, Schottky noise is always associated with 
direct current flow, for example in diodes and transistors. 
In this case the Schottky noise is associated with ihe photo- 
current generated by the photodiodes. The rms Schottky^ 
noise current I^ ^as on a photometric signal Iph is: 



1,^ [amperes) = V2qIptBW. 

where q is the charge of the electron and BW is the electrical 
bandwidth, in detectors, it is more convenient to work with 
the peak-to-peak value of the noise, which is approximately 



I, p.p [amperes) = 61, ^, = 6V 2qlphBW, 
The response on the chromatographic baseline is: 



I.p-p{AU) 



_ I, p-p [amperes] _ 6V2qlphBW 



2.3Ip[, [amperes) 



2.31 



ph 



Independent Noise, This noise term is seen as a fixed 
amount of noise superimposed on the photometric signal. 
It is mainly generated by the electronics (amplifiers, analog- 
to-digital converters, etc.) and is independent of the level 
of the photometric signal. It can be expressed as; 

Ij p.p (amperes) - constant ^ f(Iph]' 

The response on the chromatographic baseline is: 

^ I, p.p (amperes) 
'^^-r^^"^^ 2.3Iph (amperes) 

Proportional Noise. This noise term is proportional to the 
photometric signal It comes mainly from lamp instabilities 
ejndgain variations in the electronics. It can be expressed as: 

Ipp.p (amperes) - kiph = 2.3X10-^^11 
The response on the chromatographic baseline is: 
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Fig. 2, Opttcaf system of me HP 
79853 A Programmable Variabte 
Waveler^gth Detector, a forward 
optics, scanning absorbance 
detector. 
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T fAtJI^ r^.p.p (amperes) _ klph _ k^ ^ , 
ipp-pi^ J 2. 3Iph (amperes) 2.31^^, 2.3 ' 

Total Noise. The total noise on a chromatographic signal is: 



I, (AU) = Vi/ + h^ + I^,^ 

The result of this model is shown in Fig, 1. Within the 
operating range of the detector, the total noise of the system 
approaches very closely the theoretical limit, which is the 
Schottky noise. 

Variable Wavelength Detector 

Features of the HP 79853A Variable Wavelength Detector 
include high sensitivity with low noise and drift, and ver- 
satility in the form of programmable wavelengths autozero 
capability, and interchangeable cells. This detector has a 
single- channel output. Time -programmable wavelength 
switching and stop-flow scanning make it possible to take 
a spectrum to find a wavelength with optimum sensitivity 
for a given chromatographic peak, thereby achieving 
maximum sensitivity. 

Scanning Absorbs nee Detector Optics 

In the optical system of this detector (Fig. 2), radiation 
from a deuterium lamp is focused on the entrance slit of 
a monochromator by means of spherical and plane mirrors. 
In the monochromator^ a 1200-line/mm grating in a highly 
efficient Monk-Glllieson optical system spatially disperses 
the beam and focuses the selected portion of it on the exit 



slit, which has an 8-nm optical bandwidth. The beam 
passes through a flow cell which has an B-pd volume and 
a 10-mm path length, and the transmitted light is converted 
by a sample photodiode into an electrical signal. To com- 
pensate for intensity fluctuations of the light source, a 
beamsplitter in the monochromator directs part of the light 
to a reference photodiode. Wavelength selection is made 
by rotating the grating, which is driven by a stepper motor. 
An optical unit casting contains all items: mirrors, 
beamsplitter, grating assembly, and two photodiode as- 
semblies. The deuterium lamp is located in a separate com- 
partment attached to the casting. 

Flow cell construction follows a classical steel cell con- 
cept. A .steel housing contains the Suprasil windows, gas- 
kets, screws, and other parts* The inlet capillary is coiled 
around the liousing, forming an efficient heat exchanger. 
The assembly is part of a cassette that can be removed from 
the instrument for cell inspection. A simple sheet-metal 
case, which follows HP standard appearance design 
guidelines, contains all subassemblies: the optical unit 
with its cell cassette, the power supply, analog-to-digital 
and digital-to-analog converters, the microprocessor, and 
the user interface. 

Data Acquisition and Processing 

One of the main goals in designing a signal path is to 
find a solution that provides operation as near as possible 
to the theoretical noise limit, which is the Schottky noise 
of the photocurrent, This means that the electronic circuits, 
including the light source and the photodiodes. must add 
a minimal amount of noise above this limit. Other goals 
are to provide signal filtering matched to the chemical ap- 
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Fig. 3. Signal processing system of the HP 79853 A Detector. 



38 HEWIETT-'PACKARD JOURNAL APFlfL 1990 



)Copr. 1949-1998 Hewlett-Packard Co. 



plications and time tables to change parameters during an 
analysis. Fig. 3 shows the block diagram of the HP 79853A 
Detector. Light energ>* is converted to photocorrenl by sili- 
con pin photodiodes, which generate photocurrents as 
large as 10 nA. Because the light intensit\^ varies signifi- 
cantly with wavelength, the preamplifier gain is increased 
from a normal value of 1 to 2> 4. or 8 depending on the 
actual photocurrent. The next stage is a channel selector 
connecting the analog- to-digital converter (ADC) input to 
the sample or reference photo diode or to analog ground 
for offset compensation measurement. The ADC is an in te^ 
grating type with a basic conversion frequency of 1.2 kHz, 
generating a pulse width signal proportional to the input 
voltage* Twenty-four conversion cycles and some waiting 
time are summed, resulting in an 18-bit ADC with 25-ms 
conversion time. This speed is more than adequate for LC 
purposes, even for the fastest chromatographic applica- 
tions. 

As mentioned earlier, compensation using a reference 
photodiode provides advantages in suppressing common- 
mode effects. It is best to use identical parts for measuring 
the sample and reference photocurrents. Therefore, only 
the photodiodes and the first op amps are individual parts. 
All other parts in the signal path, including the ADC, are 
identical. With this design it is possible to guarantee drift 
values of less than 5x10"^ ALI per hour. 

A 7810 one-chip microprocessor clocked at 12 MHz is 
used for all control and data handling operations. Corres- 
ponding to the user-selected signal response time (0.25, 1, 
or 4 seconds) the 18-bii ADC data is low-pass filtered and 
converted to absorbance data according to the equation 

A(X.) — log (reference data) — log( sample data). 

This does not normally result in A (X) - far a nonabsorh- 
ing prohe, as required by the Lambert- Beer law, because 
the solvent itself and the eel I absorb some light. To compen- 
sate, a balance is performed. Just before starting an analysis 
the actual absorbance is measured and stored, and all future 
absorbance compulations are corrected by this value. 

The data output of the CPU consists of two different 
types: data to be displayed and data for the analog output 
signal of the detector The display is a 16-character single- 
line vacuum fluorescent display with fi x 7 dol matrix 
Gharacters. For the analog output signah a dlgital-lo-analog 
converter (DAC) operates on the digital data. 

The dynamic requirements of the DAC are determined 
by signal and noise considerations. The value represented 
by one least-significant bit must be small compared to the 
minimum signal level, which here is noise. The fuil-scale 
analog output corresponds to 2 AU (by definition], and the 
minimum noise is 2x10"^ AU. The result is that 1 LSB 
must be less than 1 x 10"^ AU or the dynamic range must 
be greater than 200>000. Consequently, an 18-bit DAG is 
needed. To obtain this dynamic range with monotonic be- 
havior, a two-stage DAC principle was chosen. The first 
stage is an 11-bit pulse width modulated DAC with 20-bit 
accuracy operating at a 183-Hz repetition rate. The output 
of this stage enables 7 bits of a second monolithic DAC. 
The two DAC outputs are added, resulting in the required 
18 bits. LoW'pass filtering suppresses the ac content to a 



negligible amount. 

Besides signal data handling, the microprocessor has 
some further tasks to perform. For safety reasons, a leak 
detector near the cell is monitored with a built-in S-bit 
ADC. In case of any malfunction, appropriate not*ready 
and error messages are activated. The microprocessor also 
generates the hit pattern for the step motor to change the 
wavelength, and takes care of deuterium lamp control, 
shutter movement for suppression of optical second*order 
diffraction [optical low-pass filter), and remote control 
input and output for synchronizing the operation of all 
connected LC modules. 

Detector Control 

Users of LC detectors are commonly chemists or persons 
in chemical labs. They need easy access to the m:ost impor- 
tant functions with a self-explanatory display and 
keyboard. This is quite difficult because the space for the 
keyboard is limited and because access to 26 different pa- 
rameters and functions must be provided. In addition, 
about ten special functions for service purposes are avail- 
able. In the HP 79853 A, the most frequently needed func- 
tions are directly accessed via corresponding keys 
[deuterium lamp on/off, start/stop analysis, wavelength 
selection, and balance). The remaining functions are access- 
ible via a special control key plus an identification number. 
All contra! functions can be reached either in this way or 
by scrolling forward and backward with up and down keys- 
The frrst five control functions are those related to spectrum 
acquisition and spectral data output. There are also auto- 
mated functions allowing tasks like finding the wavelength 
with maximum absorbance in a measured spectrum and 
switching on or off the deuterium lamp after a predefined 
time interval to extend the life of the lamp. 

Multiple Wavelength Detector 

The HP 79B54A Multiple Wavelength Detector is de- 
signed for customers who need not only signal sensitivity 
but also spectral sensitivity and more information. This 
detector features simultaneous dual- wavelength monitor- 
ing and on-line peak purity checks. 
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Fig. 4. Optica! system of me HP 79854A Multiple Wavelength 
Detector, a revoFse optics, diode array absorbance detector. 
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The main objectives for the development team were to 
achieve the highest possible sensitivity in terms of noise, 
virander and drift, to reduce spectral noise to its theoretical 
minimum, to make the instrument insensitive to refractive 
index changes v^^ith temperature, and to implement enough 
functionality to make the instrument a useful tool in both 
research and quahty assumnce labs. 

MWD Optical System 

Fig. 4 shows the optical system of the HP 79854 A, The 
radiation source is a deuterium discharge lamp that has a 
wavelength range of 190 to 600 nm. Light is collected by 
an achromatic lens system and directed onto the spectrome- 
ter slit, which is 120 ^m wide and 635 ^m high. In the 
plane of the slit a 1:2 reduced image of the lamp aperture 
is formed. The slit is part of the cylindrical flow ceil, which 
is made of quartz and has a path length of b mm and a 
cylindrical volume of 8 juh By designing for an optimum 
fit between solid angle, image size, and flow cell geometry, 
wall effects (reflections at the cell walls and refractive index 
sensitivity) are avoided and a high photon flux is achieved.^ 

A holographic concave grating disperses the emergent 
radiation linearly onto a photodiode array. The array con- 
sists of a row of 211 individual silicon photodiodes with 
a center-to-center spacing of 61 ;im. 205 diodes are used 
for the 410-nm-wide wavelengtli range, so the dispersion 
factor is 2 nm per diode. Because of the 120-ftm slit width 
the signal bandwidth is 4 nm, a trade-off between spectral 
resolution and high light throughput/ A cut-off filter 
placed before the array removes second-order spectra. 

The required spectral dispersion as a function of 
wavelength determines the groove density of the grating. 
Grating aberrations — spectral plane focus, astigmatic focus, 
and coma — have to be minimized over the spectral range 
of interest. Fabrication of a flat-field master grating is done 
via holographic recording techniques, that is, a 3D interfer- 
ence pattern is produced by two coherent point sources 
(their positions can be calculated from known imaging 
properties and the required disperslonj. By means of an 



appropriale groove profile the amount of light into a desired 
spectral order can be controlled [70% efficiency at 225 nm). 
Final grating production is by replicalion processes. 

A shutter positioned between the lens system and the 
flow^ cell can cut off the radiation for dark current compen- 
sation or interpose a holmium oxide filter into the radiation 
path. With its characteristic spectrum, the filter calibrates 
the photodiode array for a correct wavelength scale, 

The casting containing all optical components is 
mounted on a sheet-metal base, 7'he cell area and all capil- 
laries are easily accessible by opening the front door- All 
electronics, including the power supply, ADC and DAC. 
data acquisition unit, and central processing unit, is located 
behind the optics in the rear half of the box and is easily 
accessible for service and upgrades. 

For a good noise profile, the temperature variation In the 
optical setup needs lo be as low as possible. Heat dissipa- 
tion occurs at the lamp position (lOC'C] and in the cell, 
the latter caused by the flow of solvent previously heated 
in the LC column oven (up to 100°C). There is also dissipa- 
tion over the capillar>^ steel walls. Active cooling is done 
separately by two fans. The first is adjacent to the lamp 
compartmenU and the second is behind a large heat ex- 
changer. Bolh lake in air from the front of the box. A small 
heat exchanger is attached directly to the cell forfine-tun- 
ing the temperature profile* 

Signal Electronics 

Tiie self-scanning photodiode arrays are built on silicon 
semiconductor material and consist of a number of pholo- 
cells connected to a common output (video line] by means 
of electronic switches. The switches of the individual 
photocells are controlled by a shift register so that the 
photocells are read sequentially according to the shift regis- 
ter clock signal. The common output Is connected to a 
charge amplifier. 

A schematic diagram of a self-scanning photodiode array 
is shown in Fig- 5, Each photocell has an associated 
capacitor 0,1,, which represents the junction capacitance 
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of the photodiode or, in some cases, is a capacitor separately 
added on the chip* In operation, the capacitors of the photo- 
cells are initially charged to a fixed value by scanning all 
photocells. 

When photo as penetrate the photosensitive material, 
charge carriers are generated, which discharge the 
capacitors according to the nnmber of photons within a 
given integration period. When a particular photocell is 
connected to the common output, its capacitor is recharged 
from the charge amplifier and the amount of charge re- 
quired represents the discharge level of that cell's capacitor, 
which is proportional io tlie incident light level during 
that integration period. Before each charge transfer from 
the charge amplifier to a photocell, the reset switch RS is 
closed to null the charge amplifier and prepare it for the 
next transfer. 

The charge amplifier integrates its input signal so that 
the voltage change at its output is proportional to the inte- 
gral of the incident light level during the integration period. 
This signal is further processed by an aniphfier, a sample- 
and-hoJd circuit, an analog-to-digitai converter (ADC), and 
a microprocessor. 

Analog-to-Digitaj Converter 

The ADC combines the benefits of the successive approx- 
imation technique and the advantages of the dual-slope 
algorithm. The benefits of successive approximation are 
high resolution of 16 bits, or steps of 76 ^V over a 5V input 
range, and a high conversion rate of 18,000 readings per 
second. The dual-slope algorithm provides low noise, a 
good temperature coefficient, excellent differential linear- 
ity, and low manufacturing costs. The ADC is only required 
to make relative, not absolute, voltage measurements. The 
dual-slope-based conversion principle is called triple- 
slope integration because of the three different parts of the 
integrator voltage waveform (Fig. 6), 

A schematic drawing of the ADC is shown in Fig. 7. The 
input voltage coming from the photodiode array passes 
through a level shifter and a variable-gain stage before 
charging the integration capacitor. A very fast comparator 
detects the zero crossings of the integrator voltage (critical 
areas around the zero level are amplified to avoid com- 
parator toggling) and triggers the digital timing logic, which 
switches the discharge currents and controls the counters. 
After the conversion the corrected counter content is 
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loaded into the output data register as the 16-bit conversion 
result. 

One difference between the triple-slope integration 
technique and common dual- si ope techniques is that the 
integrating capacitor is charged by a constant voltage In- 
stead of by a voltage dependent current during a fixed 
charge time. Therefore, no autozero step is necessar>' be- 
tween readings to remove the charge remaining from the 
previous conversion. Thus the number of error- inducing 
high-speed switches is minimized and a typical overall 
noise level of ±0.5 LSB (least-significant bit = 76 fiV] is 
achieved- 

The other main difference solves the great disadvantage 
of the dual-slope principle, the relatively slow conversion 
rate, by using two bipolar discharging currents with a con- 
stant ratio of ii ^ - 1 28i^. The conversion rate is increased 
by a factor of about 64. An internal correction bit makes it 
possible to eliminate various switching delay errors by pro- 
viding additional time to drive the integrator voltage to the 
zero level. 

The capacitor discharge times are measured by a single 
comparator circuit to eliminate offset voltages. The output 
digital data word is the result of multiplying the upper 
nine data bits by the weight of 128 and adding the correc- 
tion bit and the lower seven data bits. 

To achieve the full speed advantages of this technique, 
a pipelined signal flow prepares the next diode voltage to 
be switched to the integrator while the current conversion 
is running. At the same time the data word resulting from 
the previous cycle is kept in the output latches to be fetched 
by the front-end microprocessor. This pipelining concept 
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reduces the timing requireinents for the processor enor- 
mousiy by keeping the computed result stable for the time 
needed for a full conversion cycle. 

A small on-board diagnostic circuit is provided to test 
the ADC with two constant internal voltages and an addi- 
tional ramp voltage covering nearly the full input range, 
using only the digital output data as test results. Thus a 
good ADC test is possible even if there are malfunctions 
elsewhere in the electronics. 

Data Processing and Architecture 

Processing is split between a small preprocessor system 
and the main processor system (see Fig. 8]. The preproces- 
sor takes care of array data readout and control of the diode 
array. The main processor is responsible for data calcula- 
tion» VO, and user interface handUng, 

HP's first fast scanning detector, the multi wave length 
HP 79880A, had a similar architecture, using a fast bit-slice 
front-end processor and a Z80A main processor; For the 
new HP 79854 A, the costly and chip-consuming bit-slice 
preprocessor is replaced by a standard 6809 preprocessor. 
The main processor is a standard 68008. Performance is 
maintained, but the chip count is reduced by two thirdst 
reliability is increased, and the cost is reduced by one third. 

The 6809 preprocessor system controls the array and 
gain switching hardware to set the correct gain for each 
diode, and it synchronizes the array cycle with the 12.5-ms 
data processing cycle. It also captures data coming from 
the ADC with a period of 55 fts (18,000 words/s], filters 
the values separately for each diode, and block- transfers 
20 raw intensity-scan records per second to the main pro- 
cessor* 

The 68008 main processor, running under a multitasking 
operating system, handles the local keyboard input, display 
output. :?nd DAC control and does the complex calculations 
necessary to provide chromatographic signals and spectra 
at I he analog outputs. Since the main-processor load is 
critical, the main processor is interrupted by the preproces- 
sor only when a complete scan record is available for pro- 
cessingK 

The main processor corrects the raw intensity data from 
the preprocessor for dark and electronic offsets. The cor- 
rected record represents the light intensity distribution 
over the wavelength range from 190 to 600 nm. This record, 
called a raw^ intensity scan, is osed to build chromato- 
graphic signals and spectra. Six raw signals are generated 
by bunching (adding) intensities in the wavelength domain 
to get the desired center wavelength and bandwidth. These 
raw signals are filtered in the time domain according to 
the required peak width, that is, the filter length and output 
data rate are set to produce the number of data samples 
needed to reconstruct the peak shape, height, and area 
correctly. To get the absorbance values, the filtered raw^ 
signals are log-converted and referenced to the background. 
Finally, the data rate is converted from the current sample 
rate to the DAC output rate to make the chromatographic 
absorbance signal available for analog output 

As shown in Fig, 8, the first step in spectrum processing 
is bunching the intensity data for each wavelength in the 
time domain up to the desired acquisition time^ which also 
depends on the peak wndth. Next, the logarithm is calcu- 



lated and the background scan is subtracted. The result, 
the absorbance spectrum, is stored in spectrum memory * 
which holds up to ten spectra. 

Calibration values, used to set the correct gain for each 
diode and to correct the raw intensity values, are measured 
during a special calibration cycle on request and the results 
axe stored in control and correction tables for continuous 
use during normal measurements. 

Detector Functions 

The user can predefine three different sample wave- 
lengths and three different reference wavelengths and 
change them in a time program. Unwanted impurities 
within a chromatogram can be subtracted from the sample 
signal by simply setting the reference to a wavelength 
where only an impurity spectral band exists. Arithmetic 
is possible not only with signals but also with spectra. 
Spectra are taken jnstaotaneously on demand or can be 
programmed and stored. Subtraction of spectra from the 
same or other runs (baseline spectra) is done off-line. 

For identification of unknown compounds, a quick 
means of creating a chromatogram with the highest signal- 
to- noise ratio per peak is desirable. Diode array technology 
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offers on-line information about the waveiength with the 
highest absorbance in the cell for each peak. This helps in 
choosing the right wavelengths for a successful time pro- 
gram. 

Troubleshooting 

Unfortunately, the detector can't tell whether unnatural 
noise or signal behavior is caused by an LC system malfunc- 
tion or a detector failure. For example, the noise might be 
loo low or too high, the baseline might be randomly or 
regularly spiked, or mi era wander and jumps might occur. 
For the multi wavelength detector, troubleshooting starts 
by exchanging the flow cell with the test cell and cutting 
off the flow path from the detector. Then the detector self- 
lest or various test functions can be invoked. Error mes- 
sages, such as leak detected, error in other module, lamp 
ignition failed, low intensity, or wavelength calibration out 
of range, may be helpful in correcting a malfunction. There 
is a lamp intensity test to check the output of the light 
source. The holmium spectrum can be measured to monitor 
stray light in the UV range, and for an electronic noise test 
the lamp is disconnected and the signal path from the diode 
array to the electronics is checked. The printed circuit 
boards have their own specialized tests. The gain factors 
of the ADC can be measured, and the DAC can be tested 
using a built-in test pattern as input. 
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Firmware Development for a Modular 
Liquid Chromatography System 

More than half of the firmware for the HP 1050 Series High- 
Performance Liquid Chromatography System is common 
to alt modules. It is customized for Individual modules by 
means of modute-specific tables. 

by Christian Biittner, Fromut Fritze, and Gerhard Pie 



EACH HP 1050 SERIES MODULE is a stand-alone 
unit, performing one specific task required in a liq- 
uid chromatography system. There are three types of 
modules: solvent delivery system, automatic liquid sam- 
pler, and detector. Combined, the modules form a com- 
plete, working analysis system. Therefore, the scope of the 
firmware implementation is the combined functionality of 
a complete LC system, but I he firmware physically resides 
in specific modules. 

Based on our experience with earlier products and the 
large number of new functions, which had to be im- 
plemented by up to ten engineers working in parallel 
within a time frame of two years, we took the trouble to 
establish a robust Brmware development process with 
some significant new approaches. Some key obiectives 
were to reuse as much code as possible , to aim for easily 
maintainable code, and to insist on identical processor and 
user interface hardware for all modules. 
Code Reuse. One of the most important goals was code 



reuse. We adapted design concepts from a previous product 
and emphasized strongly common solutions for all devices. 
For common functions, we aimed to reuse code unmodified 
from device to device. Even functions that only have com- 
mon concepts got identical code and are tailored to the 
device-specific needs by tables. 

Easy Maintainability. Both to remove defects and to en- 
hance the product*s functions, poslrelease work may be 
necessary on the code. In addition, tlie control firmware 
for future instruments may be derived from an existing 
version. This motivation affected the structuring of the 
firmware and led to the decision to write code in Pascal, 
limiting the amount of assembly language code to the abso- 
lute minimum. 

Identical Hardware. A prerequisite to making and han- 
dling a large amount of common code is the use of identical 
keyboards, displays, and micropnK:e.ssorarf.:hitecturt? in all 
modules. Fig. 1 shows the generic electronic hardware 
block diagram. The processor board, which Is common to 
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all modules, occupies one slot of the cardcage. It is based 
on a Motorola 68008 microprocessor, has 64K b\les of RAM 
with 32K batten^ powered, and can handle up to 512K 
b\^es of ROM. To keep the processor board absolutely de- 
vice independent, the ROM b physicaUy located on a de- 
vice-specific board in another slot. Integrated on the proces- 
sor board is the remote interface circuitry. The remote in- 
terface provides common conununi cation lines between 
the HP 1050 modules. Additional electronics monitor a 
safety sensor to detect solvent leaks. 

Fixed address ranges are allocated to the different printed 
circuit board slots [Fig. 2). They range in size from 12aK 
or 64K for option slots to 15K for device -sped fie slots. The 
internal bus system is designed to accept additional proces- 
sor cards in all option slots. The bus system includes all 
the necessary signals for data, addresses, interrupts, resets, 
monitoring, and control. 

Development Envfronment 

The firmware can be classified as either hardware inde- 
pendent or tightly coupled to the hardware. For software 
development we had a number of UNIX worLstations and 
terminals t while we used emulators for integration and 
tests on the target hardware. In addition, we used a central 
UNIX machine for file archiving. All UNIX machines were 
linked by local area netw^orks. while the emulators were 
linked via a high-speed link. Fig. 3 shows the development 
system architecture. 

Because only a limited number of prototypes and 
emulators were available, we made every effort to do as 
much development work on the UNIX workstations as pos- 
sible. The Pascal compiler for the UNIX workstations and 
the cross compiler for our target processor bad some incom- 
patibilities — for example, different import/export deulara- 
tions^so to achieve compatibilily we built a software pre- 

UNtX IS a reflisiered irademartt of AT&T in {he USA and oiti^sr caunineg. 
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Fig. 2. Common memory map for the HP 1 050 Series proces- 
sor 

processor that handled the differences automatically. This 
gave us the confidence that a procedure developed on the 
[JNIX workstations could be painlessly transferred to the 
target hi^rdware without error-prone manual intervention. 
Since we didn't want to expend too much effort in building 
a simulation of the target hardware, software verification 
on the UNIX workstations was restricted to the less- 
hard ware-de|iendent parts. 

Beyond the common UNIX directory structure, each de- 
veloper had the same user*s directory structure to contain 
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sources, documents, and tools. The source directories were 
set up to contain either common code used by all modules 
or module-specific sources- Fig. 4 shows the directory 
structure. 

To support the Pascal preprocessor we added include 
and object directories in parallel with each source direc- 
tory. The include directories contained constants, types, 
functions, and procedure declarations exported by a given 
source file. These were automatically generated by the pre- 
processor and helped to adjust for the different compilers' 
import /ex port concepts. The object directories contained 
either purely UNIX or target -process or relocatable code and 
made the distinction between the two more obvious. 

The preprocessor concept and its import/export require- 
ments had the advantage that we could trace all imports 
of a given file. Doing this recursively starting with the main 
program finds all needed sources. Thus, we could easily 
compile the complete system by just referring to the main 
program. Alternatively we could automatically check for 
changed sources and update the affected and dependent 
files. In the same way we were able to link all necessary 
object files into an executable file, without the burden of 
maintaining and updating make files. Again, we just re- 



ferred to the main program when calling the link utility, 
and it collected all required relocatables automatically. To 
add a new source file, we only had to add a new include 
statement to the calling source file and the tools took care 
of the compilation and linking. 

Because we traditionally use a proprietary multitasking 
operating system within our firmware, we faced the diffi- 
culty of simulating that operating system on top of the 
UNIX operating system. This allowed us to use the UNIX 
workstations to verify entire tasks including their com- 
munications. Since Pascal doesn't support switching the 
stack pointer and the program counter (necessary to swap 
tasks], we used assembly language for our target machines. 
Unfortunately, no assembler was available for our FIP 9000 
Series 500 machine, so we had to look for another solution. 
Thus we used one fork-created process per task on the 
UNIX workstations. Control between the processes was 
transferred by UNIX signals while shared memory emu- 
lated the target processors' common RAM. Although this 
isn't as speedy as an assembly language solution for switch- 
ing contexts, it worked fine for our simulation purposes. 
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Revision Control System 

The UNXX revision control system (RCS) was quite heavi- 
ly used and very^ valuable, since we had different teams 
for the various modules working simultaneously. For all 
functiouality we added scripts to access tJie RCS from any 
UNIX machine within the network. We also added proce- 
dures to check out ail files for a given source directory at 
once. This gave us the ability to maintain software packages 
as a single source directory {e.g., operating system, dialog, 
parser, etc.). From time to time, for example when new^ 
functionality was added, we had new Lncompatible ver- 
sions of a given package. To handle this we simply in- 
cremented the major number of that package's internal re- 
lease and came up with rules like; "For parser version 4.X 
you need operating system version 5.X.'* A major benefit 
of the revision control system is its ability to update a string 
containing condensed status information for a file version. 
We put this string into the obiect code and the final execut- 
able code by placing it into a string constant within each 
file (e.g., c_rcsid= SHeader: env.v 1,1 89/06/27 1 0:58:30 ffritze Exp 
$ '). Thus we had the ability lo backtrace the files associated 
with a given release by simply scanning the executable 
code or EPROM for that string constant. 

Design Overview 

In the beginning of the design process we identified all 
common function blocks and tried to structure these so 
that we could easily tailor them to each specific instru- 
ment's needs* 

Functions were segmented to minimize the interfaces 
between them. We assigned related functions to tasks han- 
dling a given set of data [e.g., parameter handler) or re- 
sources (e.g., remote control task). By assigning priorities 
for the tasks we made the real-time behavior of the module 
more responsive to hardware and user interaction. 

To allow reuse of the common generic tasks and utilities, 
we had to find a way tn adapt their behavior to each instru- 
ment's individual needs. To ensure a stable and maintain- 
able ijlatforni, we voted against individual modifications 
of comrnon code. Instead ^ we designed the tasks so that 
their behavior could be modified by supplying appropriate 
information within tables. Good performance Is achieved 
by using mostly hash tables or indexes lo address entries 
rather than interpreting through a whole table. The instrn- 
ments' behavior was completed by adding specific tasks 
(e,g.. execution tasks) and interrupt routines (e.g., hardware 
scanner). 

Task Structure and Interaction 

The system consists ot several independent tasks, as 
shown in Fij^. 5. These tasks and their interactions are 
managed by a proprietary operating system. 

To explain the interaction of the different tasks, let us 
assume that a user has just pressed a key. This is sensed 
by an interrupt routine serving as keyboard scanner, whit:h 
sends a key mail message to the dialog task. Depending on 
the contents of its tables, the dialog task changes its state, 
executes some macros, and builds up a new display by 
sending malt to the display task. The display task thus 
reflects the entry of the key to Ihe user. In parallel, the 
update task is informed of a new state and stops its periodic 



update of the display. Once the user has completed the 
instruction it is not only echoed by the display, but also 
sent to the parser. Depending on the contents of its tables, 
the parser task checks for valid range and builds an internal 
instruction. This is mailed to the parameter handler, a cen- 
tral task dealing with all instrument parameters. The pa- 
rameter handler checks the instruction for correctness with 
respect to other dependencies. To find incompatible set- 
tings before execution of a measurement, the instruction 
is sent to a verify task. Once this check is passed, the 
setpoint is stored within the parameter handler. An 
acknowledgment is sent to the parser and forwarded to the 
dialog task, the display, and the user. If the new setpoint 
belongs to the currently active parameters (called the active 
method] it is also transmitted to the execution task. Other- 
wuse, the method handler gathers the settings for later 
execution. 

Simultaneously, depending on the dialog state, the up- 
date task may query the parser for actual readings. These 
requests are forwarded directly to the responsible execu- 
tion task. The answer is translated backwards by the parser 
and mailed to the update task, which displays it via the 
display task. Independently, the hardw^are is monitored by 
periodic routines such as the remote control scanner and 
the leak scanner* Any errors or triggers [e.g,, sample injec- 
tion) arc sent to the event handler task, w^hich performs 
system state transitions (e.g., waiting into run) according 
to its state table. Triggers may also be logged into the log- 
book task, while state transitions may be reflected, for 
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example, by LED changes or remote control line settings. 
The logbook task maintains a logbook file, which can be 
accessed by a user to get information on the histor)"^ of the 
system. 

Task Configuration 

To pruvitle ii useful building block for several chromato- 
graphic modules, we had to consider the system integration 
process. It was obvious that our software development pro- 
cess bad to support parallel work on several specific and 
common tasks. All intertask communication is ac- 
complished by sending and receiving mail. To decouple 
system integration from the progress of an individual task 
or of other modules, we took a new approach to task con- 
figuration. In contrast to the more traditional close ties 
betw^een corresponding tasks [i.e., by .static tables), w^e de- 
liberately tried to decouple the individual tasks as much 
as possible. Thus we came up with an automatic mad con- 
figuration process. 

At start-up, each task registers with the operating system 
to reserve the required resources (e.g., RAM, stack) and get 
the needed priority. In this process, each task declares its 
needs with respect to mail. A ta.sk may contain several mail 
producers and consumers, These are announced to the 
operating system. As the mail manager is informed about 
the type of mail to be received or sent it performs two main 
services: it generates mail routes leading from each pro- 
ducer to all mail consumers interested in the same sort of 
message, and it assigns an appropriate number of buffers 
to each producer. This guarantees availability of the re- 
quested resources to each producer better than a common 
pool of buffers, w^hich could be easily emptied by a single 
producer. 

After initialization the multitasking starts and the tasks 
compete for CPU time. Our multitasking is not time-sliced, 
so a task continues to operate until a higher-priority task 
is scheduled or it suspends itself waiting for mail. A more 
important task is only scheduled once it receives mail, 
either from an interrupt -based scanner or from the currently 
executing task. The executing task thus gets interrupted 
and suspended while the higher-priority task is awakened 
with mail received. Thus we use a mail-driven multitasking 
system. 

Mail Management 

The smart mail management system handles alJ kind of 
situations: producers without consumers, consumers with- 
out any producers, .several producers for a given type of 
maih multiple consumers for some mail, consumers of sev- 
eral different types of mail, and producers of multiple mail 
types (see Fig. 6). This built-in flexibility allows easy addi- 
tion and integration of a now task without modifying tables. 
If a constimer never receives mail, it is not bothered and 
never a weakened. In contrast, a producer's mail that has no 
consumer is simply short-circuited back to the producer. 

This flexibility made it possible to have early working 
prototypes by. for example, defining returned mail to be 
an acknowdedgment although no one had ever received 
that maiL It also allowed easy adding of functionality. For 
example, assume w^e want to trace w^hat keys are pressed. 
We simply write a task that registers for key mail as a 



consumer. It will automatically receive all key mail, and 
its only responsibility is to forw^ard the mail after tracing* 
One can look at tasks simply as objects to be added to a 
system, while the system resolves ail connectivity and re- 
source issues. 

Table*Driven Applications 

As already explained, the objective of writing reusable 
code led to a firmware system composed largely of generic 
parts that are tailored to specific uses with the help of 
tables. 

Several ways of building ROM tables were considered: 
■ Pseudoinstructions. The tables are built by defining con- 
stants with the help of the compiler or by defining the 
memory contents with the help of assembler pseudo- 
instructrnctions such as 



DS.B 
DS.W 



VALUE 
#PROCESS_XY 



m Cross generation. The tables are generated on a remote 
computer with the help of tools on that computer (UNIX 
shell scripts, lexVacc etc.). 
B Generate tables with the help of Pascal. The tables are 
generated by a Pa. scat program that runs on the target 
processor. The program initializes a memory area for its 
own variables, which will later be used as the table. 
In the past, we have used the first method, pseudoinstruc- 
tions, for presetting memory locations (small tables, struc- 
tured constants). The pseudoinst ruction technique has the 
advantage that the assembler/linker places the defined 
bytes and words in the ROM area automatically, whereas 
with the other two alternatives this must be managed sepa- 
rately after the tables are built. The problem with this ap- 
proach is that there is no automatic link between the assem- 
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Fig. 6. Pmducericonsumer configurations for mail, A one 
producer, one consumer. B: one producer, several consurr}- 
ers. C: one producer sending mail on diffefer}t rrmi^ routes, 
D: one producer, no consumer for this type of mail. E: con- 
sumer for mail tttat ts never produced. 
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bier statements and the data structure of ihe final table. 
There is no automatic way of detecting errors in those 
tables once they are TATitten. Tj^ically the errors show up 
later at run time. With this experience in mind we rejected 
this aiternative. 

The second alternative, cross generation, has the poten- 
tial of a powerful computer with all of its tools, bill still 
has the disadvantage of not hav^ing a link between the data 
structure of the cross- generated table and the data structure 
of the programs that later interpret that table. 

The third alternative has all the disadvantages of a (t^^p- 
ical] target environment, including reduced niemor\^ space, 
no or poor operating system, and no tools. On the other 
hand, there are some important advantages. First, the pro- 
cedures building the table use the same data structure (Pas- 
cal type declaration) as the interpreting procedures. Sec- 
ond, the table generation process can use the features of 
the Pascal programming environment, including the com- 
piler (type checks). Because of these advantages, this alter- 
native w^as chosen. 

Table Generation 

Every generic Pascal procedure that has to be customized 
by a predefined table has to provide a set of Pascal proce- 
dures that can be used to build up the table. When generat- 
ing the tables, the parameters passed to these procedures 
and the sequence of the procedure calls determine the con- 
tents of the table. This process of table generation has to 
be done once before calling the generic procedure, for 
example during the start-up phase in the emulator. 

TypicaLly the code for table generation is much bigger 
than the amount of memory used for the final table. There- 
fore, the table generation code is excluded from the final 
iostrument firmware. This is achieved by burning the tables 
into ROM after a "protostarf ' program execution in which 
only the table generation code is executed [see Fig. 7), This 
burning into ROM is done together with the step of burning 
the whole firmware. 




TatH# 

Otntratton 

Cad» 



The following is an example of table generation from the 
parser table generation process: 



PROCEDURE seLcmd-tabte- 

BEGJN 

nodet LIST JisLIoken. 
Ieaf( SiGrjok_wl1. 
(eaf( RTIQV lok_rthres. 
|«af( PKWD , toM^>«*l^' 
teaf( 'OFC1 MokJcodei . 
teaf ( " AZE 1 ■ , lok . szef 1 . 
\eaii ATCA . tdcautocal. 
teaJ( PLSP', lolcplolp. 
leaf{ FMXP.tQk_maxp, 
l€af( SCNP', tok_scanp. 



END [seLcmd^iabie} ; 



lev^ 1 , tevi 7. syn_cok>n 

lev_t , mc_pafa^lr^stf . syn_signa) 
tev,l . mcjiara^instr^ syn^ratio 
i0v_1 , mc_4Jara^jnstr, syn_pkwidth 
lev_1 , mc_j>ara_in5tr, syn Jcode 
tev_l . rT)c_para_instr. syn_daczero 
lev^1 . mc jaaraJnstr. syn_on_off 
lev^l . rTK;_para_instf , syn jD^otp 
lev„l . Tnc_para^instr, syn_rnaxp 
lev_i . mc_para^instr, syn_scanp 



Node and leaf are Pascal procedures that are called to build 
up the parser tables. The parameters passed to these proce- 
dures are instruction keywords, syntax descriptors and in- 
ternal tokens for them . and the mail routes to the execution 
tasks. 

Results 

Fig. 8 shows the amount of code written for the HP 1050 
modules in thousands of noncomment source statements 
[KNCSSJ. More than half of the code (60%) is common to 
all three modules. This common code is tailored to the 
special needs of the modules by tables which are generated 
by about 15% of the code. The rest of the code (25%) is 
module-specific 

Almost all of the firmware is written in Pascal. Assembly 
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Fig, 7: Generic firmware modu/es are customized by irrstru- 
ment-speafic tables. Hie tables are generated and burned 
into ROM along witti the other firmware, but to save space, 
the labie-generation code is rtot placed iri ROM. 
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language is only used where necessary, for exannple in the 
operating system for stack pointer manipulations and iiiter- 
mpt handling or for performance reasons like the RAM test 
during the start-up phase and data acquisition in the detec- 
tor. 

Strict use of the revision control system (RCS) helped us 
manage the potential prol^lems of incompatible versions 
of up to 20 tasks. Automatic task configuration and the 
automatic include and compile- if necessary mechanisms 
helped the firmware engineers change or add tasks without 
knowing about the complete system in detaiLThe high level 
of common code gave us: 

m Three times as much test time on the common firmware 
parts as on instrument-specific parts. Therefore, the com- 
mon firmw^are parts turned out to be very robust. 

■ Common understanding and knowledge of the firmware 
in each instrument on the part of all firmware engineers 
working on that project. This put us in a position to 
balance manpow^er among the teams working on a spe- 
cific instrument. 

■ Early prototypes for both hardware and user interface 
tests as a result of concentration of effort on the common 
firmware parts at the very beginning. 

■ The basis for future enhancements that are common to 
all instruments (e.g., communication interfaces). 

■ The basis for new instruments to be developed. 

In the future, the extensive use of tables will allow^ us 
to enhance the functionality of the instruments incremen- 
tally, or to modify, for example, the user interface without 
altering the common firmware parts. Our experience has 
shown that modifying the tables is almost always bug- free 
the first time. Also, improvements of the common firmware 
parts in terms of performance or functionality always count 
three times. 
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HP Open View Network Management 

HP OpenVlew is HP's first set of integrated hardware and 
software products designed to address the needs of 
managing open, standards-based, multi vendor networks 
in a consistent, user-friendly manner. 

by Anthony S. Ridolfo 



NETWORK OPERATORS RUNNING a large com^ 
puter center are often confronted with questions 
like the following: 

Why can*t I connect to the system? 

How come response is so slow? 

What*s wrong with the electronic mail system? 

What computers can I connect to from my terminal? 

Network managers are also confronted with questions 
dealing with network planning, inventory control, and ac- 
counting. Some typical network management questions m- 
clude: 

What is the overall load on the network? 

Which systems are bottlenecks in my network? 

How^ can 1 plan for new components in my netw^ork? 

What equipment do I really have, and w^here? 

As departments, sites, and whole companies (referred to 
as "enterprises') integrate and interconnect their data pro- 
cessing tasks, the job fyf managing these complex netw^orks 
of computer and data communications equipment becomes 
Increasingly more Important to a company's bottom line. 
Monitoring the heahh of a network, diagnosing problems 
as quickly as possible, control Hng the individual compo- 
nents, adjusting net work- wide parameters and configura- 
tions, accounting for use of network resources, and plan- 
ning for future expansion are the objectives of network 
management ap[jlir:alions. 

These tasks would be relatively simple jf all the compo- 
nents in a network came from the same vendor. How^ever- 
it is indeed rare that all links in a network such as modems, 
modem cables, multiplexers, pods, LAN connectors, LAN 
cards, LAN cable types, bubs, bridges, servers, gatewayn. 
and PBXs come from the same vendor. There are also dif- 
ferent personal computers ♦ workstations, minicomputers. 
and mainframes. And there are different wide area point-to- 
point networks, public and private X.25 packet switt:hiug 
networks, and a company's enterprise-wide networks that 
may even link to their suppliers' and distributars' net- 
works. 

The computer industry and international organizations 
such as ISO ( Internal ionai Organization for Standardiza- 
tion) recognize the need to standardize communication and 
netw^ork man^igement protocols. It is HP's staled objective 
to be the leader in open, standards-based, muitivendor net- 
working. This includes the capability to manage and be 
managed by standards-compliant applications running on 
equipment supplied by any vendor. 

However, having applications that can access and control 
a network is not enough to address the needs of network 



managers and network operators. Each type of equipment 
to he managed has its owm particular command interface 
and management capabilities. Therefore, a unifying, con- 
sistent, user-friendly interface is needed for these applica- 
tions, 

HP Open View 

The HP Open View network management family is de- 
signed to address these needs of managing open, standards- 
based, mu hi vendor networks in an open, consistent, user- 
friendly manner. The HP Open View products provide a 
consistent user interface and an integrated environmeot 
for monitoring, diagnosing, controllingp and measuring the 
performance of network components. From a single dis- 
play, a netw^ork operator can see a graphic:al representation 
of the network components and their interrelationships, 
make configuration changes, and run diagnostic and perfor- 
mance gathering applif:ations. 

1'he design philosophy for the HP OpenView products 
is to create for the end user an easy to iearn. easy to re- 
member paradigm for accessing sophisticated network 
management applications. HP OpenView Windows, w^hich 
is the HP OpenView product that provides the user inter- 
face, runs on an HP Vectra ES/12 personal computer as a 
Microsoft* Windows application. Each of the HP Open- 
View products, in turn, runs under HP OpenView Win- 
dows. The user first runs the HP OfjenView Windows draw 
fOVDraw) program that allows the u.ser to draw a map f)f 
the network, with specific icons representing network de- 
vices, such as an HP 3000 business computer or a bridge 
{see Fig 1). The user then .saves this map, and runs the HP 
OpenView Windows run -time program (OVRun). LIik map 
becomes a dynamii;, graphical shell for accessing the appli- 
cations running under HP OpenView Windows, In addi- 
tion, if there exists an application reporting the slate of a 
device to the HP OpenView system, the current operational 
health of the device is indicated by the color of the specific 
icon (e.g,, red for critical, yellow for warning, and green 
for OK), 

Suppose the network operator wishes to set some param- 
eters on a specific bridge on the network. The operator 
would click the mouse on the symbol representing the 
specific bridge and select the menu item Set Parametars,... 
This selection causes HP OpenView Window^s to pass pro- 
gram control to the HP OpenView BridgeManager software, 
which puts up a dialog box for this function. Supposft now 
the operator needs to set parameters on a specific HP 3000 

MiCfQSoft IS a U S regi^ereri ffadefnark ol MicroscjfT Corp 
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datacom and termmal controller (DTC). Aj^flin. iht; operator 
selects the specific icon and then the Set Parameters,., menu 
item. Program control now passes to the HP Open View 
DTC manager, which puts up the relevant dialog box for 
this function. At no time does the operator m^.ed to know 
which product to invoke, or how to invoke it. HP Open View 
Windows and the graphical shell perform this function hy 
controlling what menu items are enabled for which devices 
or icons. The user is relieved of the need to know what 
actions are legal or illegal for a particular type of device. 
The article on page 60 describes HP Open View Windows 
in more detail 

This type of intelligent user interface is important in 
network management because network operators usually 
do tests ns <\ response to an alert of some kind, such as an 
icon changing color on the display. They do un\ perform 
testing and diagnostic functions all the time, or even on 
the same equipment. It is therefore important to maximize 
the familiarity of the user interface as well as to minimii^e 
the number of ways the user Invokes functions to do similar 
tasks. HP Open View Windows and its supporting applica- 
tions help with this task by providing a context sensilive. 
interactive system for guidance. 

Network Management Applications 

The HP Open View articles in this issue describe the de- 
velopment efforts aod the underlying architecture of the 
initial set of network management products in the HP 
Open View family. These products include: 
■ HP Open View Windows. This product provides the user 
interface to network management applications and a set 
of utilities that enable developers to create network man- 
agement applications to run in the HP Open View Win- 
dows environment. HP Open View Windows is divided 
into two main parts: the end user run- time product and 
the HP OpeoView Windows developer's kit, The end 



user run-time product includes the hardware and soft- 
ware required to use HP Open View Windows. The de- 
veloper s kit idchides the end user run-time product and 
the necessary libraries, include files, sample source code, 
and documentation to facilitate the developer's task of 
creating a Microsoft Windows application that can be 
integrated into the HP OpeoVHew eod user run-time 
product. The HP OpenView developer's kit includes a 
style guide for helping developers ensure that the de- 
tailed look and feel of their dialog boxes are consistent 
with other, iridependenlly developed applications. 

■ HP OpenView Windows BridgeManager. This product 
provides centralized monitoring and control of HP 
28B48B 10-Mbil/s LAN Bridges and HP 28647B StarLAN 
Bridges (revision B bridges only). Using the network map 
feature of HP OpenView Windows, bridges can be easily 
labeled and uientified. Menus allow quick access to a 
variety of bridge management features^ including config- 
uration, monitoring, control, performance management, 
and problem identification. The HP OpenView Bridge- 
Manager is descrilied on page 66. 

■ HP OpenView Data Line Monitor. This product provides 
the ability to monitor 4-wire leased point-to-point analog 
data lines using an HP 4948 A In-Service Transmission 
Impairment Measuring Set controlled from the HP Open- 
View workstation. It is a network monitoring system that 
can measure performance and aid fault isolation during 
troubleshooting while the network is being used. The 
HP OpenView^ Data Line Monitor is described on page 7T 

■ HP OpenView DTC Manager. I'h i s prod u ct provi des cen- 
tralized ajid integrated network management for both 
terminal connectivity and X.25 networking. It config- 
ures, monitors, diagnoses, controls, and downloads soft- 
ware to DTCs (datacom and terminal controllers). From 
a single HP Vectra running HP OpenView Windows and 
the DTC Manager, an operator can manage local and 
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Fig. 1 . An HP OpenView Windows 
map showing the network config- 
uration for a computer center. 
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remote terrainal connections and remote system-to-sys- 
tem communications across multiple DTCs on a LAN. 
The HP Open View DTC Manager is described on page 76. 
m HP OpenVtew NS Monitor. This is an internal HP tool 
developed to test and refine the HP OpenView architec- 
ture and the facilities provided by the HP OpenView 
Windows software. It is not available as a product. It 
provides network management services in the form of 
centralized or distributed network status, diagnostic, and 
performance monitoring for HP 3000 computers running 
the MPE V operating system. The user interface softw^are 
runs on an HP Vectra personal computer under HP Open- 
View Windows p and the programs that perform the diag- 
nostic and performance monitoring run on an HP 300U 
computer that is designated as the management node. 
The systems being managed are called managed nodes. 
The user interface software on the Vectra and the pro- 
grams on the mancij^ement node communicate with each 
other via HP OfficeShare on the Vectra and NetlPC on 
the HP 3000. These products are described on page 85. 

Conclusion 

A direct result of the HP OpenView^ design philosophy 
is that application developers have to learn to split the 
functionality of their products between the network man- 
agement functions and the user interface code. This is in 
alignment with HP's NewWave philosophy and the vision 
of truly distributed applications. Although networic man- 
agement products address a very specific end user, the 



architecture and implementations used to develop the 
products mentioned above represent the future of computer 
applications. The article on page 54 describes the HP Open- 
View network management architecture that provides the 
models to guide the planning, analysis, and design of net- 
work management products developed to run in the HP 
OpenView Windows environment. 
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HP OpenView Network Management 
Architecture 

This article highUghts the principal objectives of the 
architecture and the reference nrjodels used to support 
the HP OpenView product development. 

by Keith S. Klemba^ Mark L. Hoerth, Hul-Lin Lim, and Maureen C. Mellon 



THE USE OF INFORMATION NETWORKS in com- 
mercial, government, and academic organizations 
has exploded in the 1980s. With wide and local area 
networks, computing power has migrated from a centralized 
to a distributed environment. This hiiS reduced costs, en- 
hanced cumpetiliveness, and renewed organizational 
creativity. The explosion in the number of networks and 
network devices from a variety of vendors has caused a 
dramatic increase in network complexity and an acute need 
to manage these distributed resources more effectively. 

The need for network management is apparent today 
throughout any organization deploying networks. The en- 
PC/Term 



terprise network in use by many organizations includes 
both local and wide area networking technologies and an 
assortment of network devices from different vendors^ and 
is managed by a team of professionals in different geo- 
graphic areas. Fig, 1 shows the domain of a typical enter- 
prise network. 

Companies are now using information management to 
gain a competitive advantage by delivering goods and ser- 
vices faster and more efficiently. While the benefits of net- 
work management are most apparent during a crisis, they 
are no less important in day-to-day network operation to 
control network faults, configurations, performance, orse- 
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Fig. 1 . Typical enterprise network inciudes both local and wide area netorking technologies 
and an assortment of network devices from different vendors 
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Cll^^t>^ An integrated network management system can save 
time and money by reducing downtime and performance 
probiems. 

Problems of Stand-Alof^e Element Management 

During the last decade, most of the computer and net- 
working industry focused on the rapid evolution of network 
technology to the neglect of network management products. 
As the Deed for network management became apparent, 
the first products made availahle were stand-alone element 
managers. These products manage a particular set of net- 
work elements, such as bridges, modems, or routers. As 
more devices are included in the aetworkv the network 
manager must add more stand-alone element managers. 
With no correlation, aggregation, or prioritization of infor- 
mation across applications or consoles, it quickly becomes 
impossible for the network manager to use this large 
number of element managers effectively. Typically, each 
element manager uses a different user interface and style 
of operation, so that different training and expertise are 
required for each system. 

In contrast, an integrated network management system 
like HP Open View combines and consolidates the manage- 
ment of network elements from various vendors. It allows 
the customer to monitor, controK aulomatej and repair net- 
work segments and equipment from a single console and 
user interface. 



to this catego^>^ The computation netvv'ork layer includes 
networked systems and netvt^orked data bases. The net- 
worked applications layer consists of distributed applica- 
tions in areas such as X.400 electronic mail, electronic data 
interchange, and office automation. 

FuDCtioaal Requirements. HP defines several specific func- 
tionai areas for netw^ork and system management. Fault 
management provides the abilit^^ to identify, diagnose, and 
resolve network problems quickly. It also includes status 
monitoring, alarms and alerts, and predictive expert system 
tools. Configuration management delivers the ability to 
track network and device configurations from a central 
control point. Performance management provides the abil- 
ity to optimize network performance through the collection 
and analysis of device performance data. Accounting pro- 
vides the network manager with network use information. 
Security protects the network and its components from 
unauthorized intrusion or surveillance. Inventory manage- 
ment addresses the need to track, monitor, and maintain 
assets over a wide geographic area. 

The foundation for integrated network management is 
vendor support and servnce. Faced with budget constraints 
and a shortage of skilled staff, network managers need plan- 
ning, implementation, and operation support. Consulting, 
training and support services can speed the implementa- 
tion of integrated network management and ensure its effec- 
tive use. 



Dimensions of Integrated Network Management 

The problem of managing the enterprise network can he 
divided into three components: the users of network man- 
agement, the objects to be managed, and the functional 
needs of network administrators* Each component influ- 
ent :e^s network management architecture by imposing re- 
quirements for effective management. 
Users, There are several users of network management. 
The corporate network manager works at the executive 
level and is concerned about network costs, uptime, and 
strategic planning. The main objectives are to control the 
network asset and obtain consistent, maximal performance. 
Telecommunications and M(S directors implement and op- 
erate large portions of corporate wide area networks. These 
managers are concerned about network growth, uptime, 
and planning. At the loc;al area network level, data com- 
munications specialists, system operators, and site tele- 
communications managers oversee vkfork-group networks 
in environments ranging from engineering research and 
development to manufacturing plants to business offices. 
Users of local area networks rtjlv un their managers to main- 
tain the connection into the local EDP environment, pro- 
vide assistance with personal computer software manage- 
ment, and keep the network operating during critical 
periods. 

Resources to Be Managed- These fall inta four categories 
or layers, as sliown in Fig. 2, The transmission layer, which 
corresponds to the first layer in thelSOOSI modeh includes 
the physical media, such as Tl multiplexers, modems, 
broadband cable, fiber optic cable, and the like. The data 
network layer, which includes transports and services, 
covers LAMs. X.25 and SNA networks, and OSI services. 
A growing number of customers are adding voice elements 



A Standards- Based Architecture 

The HP OpenView network management architecture 
(NMA) is rooted in intern at ionid and de facto industry 
standards, ''^"^ HP OpenView NMA is based on the Open 
Systems Interconnection (OSI] management framework 
and models developed by the International Organization 
for Standardisation (ISO). Standards provide HP Open- 
View NMA with a solid foundation for providing in- 
teroperability in heterogenous, multivendor enterprise net- 
works by defining network management protocols and 
mechanisms for sharing management information. As a re- 
sult, products based on HP OpenView NMA can be used 
to manage any type of network that conforms to the OSI 
standards. HP OpenView NMA derives three essential ele- 
ments from the OSI standards on which it is based; a net- 
work management framework, a well-defined mechanism 
for describing managed objects, and a set of services and 
protocols for communication. 



Metworftttd AppUcaUons 



DvtaBaSM 



Osta Seivtoos 



N«twori( Transport 



ProoMalng Ele«fi«nit 



Trttfisffttiskm 



F Ig. 2, Network resources to be managed fail tnto to ur layers . 
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081 System Managemerit Model 

In 1988. the ISO specified the OSI System ManagemenI 
Model as a basic framework for network management. In 
the OSI model, a manager process is responsible for realiz- 
mg the specific management functions requested by the 
user through inleractions with agent processes. The agent 
processes represent the management services offered by 
managed objects.'* Possible management services include; 
m Operations such as reading a counter 
m Actions sucb as resetting a network device 

■ Notifications [known as events) such as an indication 
that a threshold has been exceeded. 

Fig. 3 illustrates the OSI System Management Model. 
The manager process and the agent process use a Common 
Management Information Protocol (CMIP) to exchange 
management information.'' The interface labeled A is the 
only open integration point in the OSI System Management 
Model. The management services offered by managed ob- 
jects at this interface are defined through the use of a stan- 
dard specification scheme known as the OSI Structure of 
Management Information,^ The interface labeled B is an 
unspecified integration point that can be implemented 
using industry-standard or proprietary protocols. 

OSI Object Model 

The Structure of Management Information is a set of rules 
or guidelines for defining classes of managed objects. The 
rules are used w^hen defining each class of managed object 
to ensure specification uniformity Glasses of managed ob- 
jects can be defined for any manageable network resource. 
For example, there can be a managed object class that de- 
scribes LAN bridges, another that describes computer sys- 
tems, and a third that describes network equipment in gen- 
eral. 

Object classes are defined by specifying their attributes, 
operations, actions, and events. Once an object is defined, 
it is placed within a registration hierarchy and a unique 
class identifier is assigned by the registration authority. 
For example, a managed object describing a piece of net- 
work equipment might have: 

■ Attributes detailing its physical location, state, and per- 
centage of utilization 

■ Actions to request its activation or deactivation 

■ Events such as alarm and change reporting. 

The use of an object model is important because it brings 
with it the concept of inlieiritance. In the context of network 
management, inheritance allows refinement of existing 
classes while ensuring compatibility wath existing soft- 
ware. The inheritance relationship that exists between ob- 
ject classes is important because it allows existing manage- 
ment applications to work with the new object class, and 
it provides a mechanism for software reuse. 

The set of managed objects within a system constitutes 
that system's Management Information Base.^ histances of 
managed objects exist within a containment hierarchy re- 
ferred to as a contoinmenl tree. For example^ a real open 
system (computer) would contain numerous managed ob- 
jects such as a routing tablOr which would contain entries, 
or an n-layer protoc:ol, which would contain n-layer con- 
nections. Some of the benefits associated with the contain- 
ment relationship are: 



■ If a managed object is deJeted^ all managed objects con* 
tained within it are also deleted, 

m Management requests can be directed to a group of ob- 
jects related by containment using scoping. 

Beyond the OSI Standards 

IIP OpenView NMA specifies a complete environment 
of services and facilities available to management applica- 
tions distributed throughout the network. This vision of 
HP OpenView NMA requires the addition of architectural 
components beyond those described in the OSI System 
Management Model 

The HP OpenView NMA reference model illustrated in 
Fig. 4. has nine components. It refines the OSI model with 
three major extensions, which are essential to the manage- 
ment of complex, m u It i vendor enterprise networks. First, 
HP OpenView NMA creates a distributed network manage- 
ment communication infrastructure consisting of three 
components known as supen^isor (S)p postmaster (P), and 
communicotioii profiles (C). Second, HP OpenView NMA 
adds an additional point of integration by dividing the 
manager process into a management oppiicatioii (A) and 
a user interface [U]. Third, HP OpenView NMA extends 
the object-oriented paradigm in two ways. The need for 
managed object persistence is addressed with the specif ica- 
tion of managed olijecl dniu stores [Dj. The scheme used 
to define managed objects (OJ is also used to specify key 
application functionality in the manager process as a man- 
aged -object, making the management services (Mj it pro- 
vides available for reuse. This provides another open point 
of integration. Finally, environmental services (E) are the 
services provided by the native operating sy.stem and these 
can be used by any of the other components. 

HP OpenView Object Model 

Object-oriented concepts and technology 
are fundamental lo HP OpenView NMA. The 
architecture reduces the multidimensional 
problem illustrated in Fig. 1 to a single dimen- 
sion by using a common object model for de- 
scribing all resources to be managed, HP OpenView^ NMA 
uses the concepts defined by the OSI standard for describ- 
ing managed objects ^ HP OpenView NMA supports the 
.structures of management information used by the OSI 
model and the Internet Engineering Task Force (IETF). HP 
OpenView NMA also provides support fur managed objects 
defined in the ISO and IETF management information bases 
and is expandable to include objects defined by developers 
for special purposes. 
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Managed objects are an abstraction of the real resouices 
being managed. The management sendees [M] offered by 
a managed object consist of the software (programs) neces- 
sar\' to provide tlie sennces defined in the managed object 
specification. This software may contain several parts, such 
as the infrastmctiire interface, an object manager, and en- 
vironmental sendees (E) necessan^ for communication with 
the real resource. 

HP OpenView NflviA extends the OSl object model by 
describing managed object data stores. These are identical 
to managed objects except that they are persistent. In the 
OSl model, managed objects are volatile. The managed ob- 
ject data stores model a mechanism for maintaining infor- 
maEion about managed objects even when networks or sys- 
tems are powered doum. 

Distributed Communications Infrastructure 

Network management is a distributed activ- 
ity' in that the user interfaces, management 
applications, and management services can 
be located in different systems throughout a 
network. The HP OpenView NMA communi- 
cations infrastructure (Fig. 5) provides the facilities for es- 
tablishing and maintaining communication between these 
components. The communications infrastructure consists 
of the postmaster (P). the supervisor (S). and communica- 
tions profiles (C). These components draw heavily upon 
the environmental services (E) to carry out their functions. 

The postmaster (P) provides basic message routing ser- 
vices between the network management components Hsted 
above. It operates as a table-based object-oriented message 
router. The routing table shown in Fig. 5 is the focal point 
of the postmaster's functionality and is itself a managed 
object. Given a message [perhaps from an application) ad- 
dressed to a specific managed object, the postmasler looks 
up the managed object name hi the routing table to find 
the information necessary to deliver the message to the 
managed object. The fields in the postmaster's routing table 
provide the managed object name, the communication pro- 
hie number, and profile-specific data. 

The information required to perform the name-to-address 
translation can be obtained from a directory service. The 
post master can make use of the directory service through 
the supervisor, whicb has the responsibility for creating 
and maintaining the routing table. However, the postmaster 
must be able to operate independently in case these sup- 
porting services fail. The routing table can be considered 
a cache of information derived from directory services and 
other sources. 

The supervisor (S) administers the existence of and ac- 
cess to all the components associated with the communica- 
tions infrastructure. It has the authority and the ability to 
initiate, cancel, lock and unlock, and control access to man- 
agement services within its supervisory domain. 

The HP OpenView NMA process of exchanging manage- 
in tint information is adopted from the OSl framework. An 
application layer network management protocol supports 
transaction -oriented exchanges between the distributed 
processes, HP OpenView NMA supports formal and de facto 
industry-standard protocols with a common network man- 
agement communications application program interface 



based on the OSl Common Management Information Ser- 
vices (CMIS)7 In an OSl environment, CMIP (as shoum in 
Fig. 5) would be the network management protocol of 
choice. In an Internet TCP/IP environmenh the most wndeiy 
used prolocols are the Simple Net\^^ork Management Pro* 
tocoJ (SNMP. specified in RFC 1098) and CMIP over TCP/IP 
(CMOT, specified in RFC 1095). HP OpenView NMA sup- 
ports not only these network management protocols but 
also the addition of proprietary protocols under the com- 
mon application program interface for complete integration 
in a mn hi vendor, heterogenous netw^ork. Each protocol 
stack is modeled as a communications profile managed 
object; this allows extensibility of the communications in- 
frastructure illustrated in Fig. 5. 

The envirormiental services (E) represent the facilities 
provided by the environment in which the network man- 
agement solution must operate [e.g.* HP-UX, MPE, MS- 
DOS J. The capabilities provided by these environments 
can be used by any of the components of HP OpenView 
NMA. In this context, these services could include the file 
system ^ the X.500 naming system, or proprietary network 
management protocols. It is also possible that some of these 
services could become part of a managed object. For exam- 
pie. a managed object that is responsible for report gener- 
ation and delivery ser\'ice would collate the information 
to be presented in the report, create a file, and deliver it 
to any requesting application using a file transfer environ- 
mental service such as FTAM (File, Transfer, Access, and 
Management]. 
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Fig. 4. Components of the HP OpenView network manage- 
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Multiple User Interfaces 

HP OpenView NMA specifies the user inter- 
face as a separate component of the network 
management solution. This addresses the 
need to allow users to access network manage- 
ment solutions from a variety of devices, 
which may include dumb terminals, workstations with 
graphic displays, voice, or any appropriate devices. It also 
addresses the need to he able to build solutions that meet 
individual users' requirements so that only relevant infor- 
mation is provided. 

The separation of the user interface from the management 
application provides an additional point of integration so 
that several management applications can drive a single 
display or several displays can be driven by a single man- 
agement application. User interfaces can be distributed 
tliroughout the network using environmental services (E) 
to access remote management applications (A). 

Extension of the Object-Oriented Paradigm 

HP OpenView NMA extends the power of 
the object-oriented paradigm as specified in 
the OSl model by treating portions of applica- 
tion functionality as managed objects* These 
managed objects are defined using the same 
object specification techniques described previously. The 
result of this approach is that value-added appUcation func- 
tionality that was previously only available within a given 
application now becomes available as a source of informa- 
tion or services to other management applications. This 
encourages the full integration of products into a hierarchy 
of management solutions while reducing duplication of 
functionality and many concerns about consistency. Thus, 
what was previously a monolithic application is decom- 
posed into a much reduced management application with 
an accompanying managed object that offers management 
services identical to the value-added functionality that was 
previously locked within the application. 

The additional point of integration provided by HP Open- 
View NMA between management applications and these 



u 


S 





A 


P 


M 


E 


c 


D 



managed objects also opens functionality for wider use by 
more applications. Consequently, HP OpenView NMA 
facilitates the development of applications upon a base of 
existing managed objects. For example, a traditional fault 
application would include event processing capabilities. 
When a configuration application is to be installed in the 
same system, it would not normally have access to event 
processing in the fault application, and would have to du- 
plicate that functionahty. HP OpenView NMA encourages 
the specification of event managers as managed objects, 
thereby making event management services available to 
other management applications. 

These managed objects can provide services not only to 
management applications but also to other managed ob- 
jects. HP OpenView NMA describes a scheme in which 
the most significant value-added portions of a network 
management solution are described as managed objects, so 
they can be linked into management chains^ providing com^ 
prehensive services to management applications. 

Conclusion 

it is important to stress that HP OpenView NMA is in- 
tended as a reference model for developers of network man- 
agement products. Xi is not intended to mandate the im- 
plementation of all the components described above. 
Neither are the components intended to define program or 
process boundaries. Products implementing HP OpenView 
NMA may range in complexity from bridges to complete 
systems. Bridges, for example, may only implement the 
management services defined for the bridge managed object 
class along with a specific protocol stack. The remaining 
components could be distributed on other systems as 
needed. 

Initial HP OpenView products implement portions of HP 
OpenView NMA. For example, HP OpenView Windows 
(see article, page 60) provides a rich environment for de- 
veloping graphic user interfaces customized for network 
management. Newer HP OpenView products wHl Imple- 
menl more features of the architecture. 

In summary, HP OpenView NMA uses the OSI standards 
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to manage muJtivendor environmeDts. It refines the stan- 
dards to introduce additional points where integration of 
products can take place and by doing so reduces duplica- 
tion of product functionality. It also allows for customiza- 
tion to support specific network management activities by 
building on an existing base of managed ohjecfs. 
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HP OpenView Windows: A User Interface 
for Network Management Solutions 

HP Openview Windows provides a consistent grapliics- 
based user interface for users of network management 
applications, and a set of utiiities ttiat enabie developers 
to create network management applications for the HP 
OpenView Windows environment. 

by Catherine J. Smith, Arthur J. Kulal<ow, and Kathleen L. Gannon 



HP OPENVIEW WINDOWS is a graphical user inter^ 
face based on the Microsoft Windows environment 
that provides facilities for handling the user inter- 
face for network management applications, For application 
developers ^ HP OpenView Windows pro%ddes programs to 
carry out tasks such as dntwing a network map or handling 
alarms. From the end user's perspective. HP OpenView 
Windows combines the functionality of many of the user's 
network management applications under one easy-to-use 
interface, simplifying the learning curve. 

This article describes the features provided by HP Open- 
View Windows to developers and users. Some of the other 
HP OpenView^ articles in this issue describe the details of 
interfacing to HP OpenView Windows. 

Overview 

HP OpenView^ Windows consists of three programs: OV- 
Draw, OVRun, and OV Admin. These three programs provide 



the folio vtfing functionality: 

■ OVDraw, This program allows users to create maps made 
up of one or more pictures ihyt represent a diita network. 

■ OVRun. This program provides the facilities that allow 
users to monitor, diagnose* and control their netw^orks. 
OVRun uses the maps created with OVDraw. 

■ OVAdmin, This program is used to set operating charac- 
teristics for HP OpenView^ Windows and HP OpenView 
applications. These include functions such as assigning 
passwords and setting up network management param- 
eters. 

The graphical user interface consists of maps, pictures, 
and symbols used to represent a network. A map depicts 
the whole network and is made up of pictures, each of 
w^hich show^s a portion of the network. For example, a map 
may represent a network for a group of buildings, while 
each picture of the map shows the network for one of the 
buildings. Pictures are composed of symbols that portray 
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network components, such as cornputers* modems, bridges, 
X.25 switdies, lines, or a portion of a network {subnet). 
The svTnbcrls provided by HP Open\''iew Windows are 
shown in Fig. 1. Subnet symbols are special symbols that 
are used to signify what is contained in another picture of 
the network and to help the user navigate around the nel- 
worL As will be shown later, subnet symbols can be used 
to represent the net^vork configurations in different loca- 
tions (e.g.. different buildings). 

Svinbols also provide configuration and status informa- 
tion- Network topolog}^ information is provided by the way 
in which symbols depict connections between components 
in a network. Status information is provided by the colors 
of the symbols, which represent the condition or state of 
each device. Netw^ork status is discussed later in the article. 

The user gives instructions to HP Op en View Windows 
and HP OpenView applications via a combination of sym- 
bols, menus, and dialog boxes. Symbols represent the net- 
work components described above, and they are used to 
select the network component the user wishes to work on. 
Menus and menu items represent the operations the user 
can select to perform network management functions. 
Menus and menu items may be standard HP OpenView 
menus or menus added by an application- Dialog boxes 
allow the user to give instructions to an application* The 
overall structure and capabilities of dialog boxes are pro- 
vided by Microsoft Windows. The content of a particular 
dialog box is provided by the application, 

HP OpenView Windows provides a large part of the user 
interface for applicationSp but applications must provide 
part of the user interface. Applications can add to the HP 
OpenView Windows user interface by creating new menus 
and adding new menu items, and by adding dialog boxes. 
The articles on pages 66, 71, and 85 describe adding menus 
and dialog tioxes to HP OpenView^ Windows. 

The HP OpenView Windows product is divided into two 
categories: end user products and a p pi i cat ion dfiveloper 
products. The end user products contain the hardware and/ 
or software components required to use HP OpenView Win- 
dows. The software component includes the tliree pro- 
grams OVRun» OVAdmin, OVOraw, and one or more HP Open- 
View applications- The recommended hardware configura- 
tion consists of the HP Vectra model ES/12 personal com- 
puter with a 40-megabyte hard disk and a 2M-byte ex- 
panded memory board. For developers the key product is 
the HP OpenView Windows Developer's Kit, wtiich con- 
tains the HP OpenView Windows end user software and 
the pieces needed to develop HP OpenView Windows ap- 
plications- 
Application InstaMation 

When the HP OpetiV^iew Windows software is installed 
on the Vectra, it creates two sections in the Microsoft Win- 
dows WIN.IM file. The two sections are e 'a lied OpenView nnd 
Open View Apps. The OpenVfew section contains information 
such as the default network ru^p and the name of I he file 
used fnr logging, The OpenViewApps section contains entries 
for tip OpenV^iew applications, which are filled in when 
applications are installed. An entry in the OpenViewApps 
section is in I he following format: 



[OpenViewApps] 

AppName - AppHun.Exe,AppDraw,&(e,AppAdmin.Exe 

AppName is the apphcation name. Af^Run.Exe is an execut- 
able file to be started when the end user runs OVRun, 
AppDraw.Exe is an executable file thai is started when OVOraw 
is run. and AppAdmin.Exe is the executable file started when 
OVAdmin is run. Applications don't need to have exec Utah les 
for all three HP OpenView programs. 

When an HP OpenView Windows apphcation is in- 
stalled, it is registered with HP OpenView Window^s 
through the entry in the WIN.INt file. HP OpenView^ Win- 
dows applications also register for graphic symbols and 
menu items. Registration for s>'Tnbols (or objects in Micro- 
soft Window^s terminology) and menus is accomplished by 
calls to HP OpenView Windows intrioslcs. 

When one of the HP OpenView Windows programs 
(OVRun, OVDraw, or OVAdmin) is started, HP OpenView Win- 
dows checks the WINJNI file and invokes ail the HP Open- 
View applications installed there. When an application is 
invoked, its WinMatn loop is entered and the first HP Open- 
View Windows intrinsic called is OVInit( ). whicii sets up 
communications between the application and HP Open- 
View^ Windows. The application then calls OVRegistert ) to 
inform HP OpenView^ Windows what object types (sym- 
bols) the application manages, and OVMenuAdd{ ) and OV- 
M en u Add Item ( ) to inform HP OpenView^ Windows which 
menus and menu items are valid for the given object types. 
The application informs HP OpenView W^indows that the 
initialization is done by calling OVInitComp(ete( ]. 

Four main facilities are provided by HP OpenView Win- 
dows: map handling, menu integration, status, and context 
sensitive help. 

Map Handling 

When w^e started con.sidering the requirements for a user 
interface for network management applications, it was ob- 
vious there was a need for a graphics -based user interface. 
Typically the way network managers and operators use a 
network management application is to draw a picture of 
the netw^ork on paper, annotating the drawing with identifi- 
cation and other information. The data from the drawing 
is used to tell the network management application which 
network components to manage. 

HP OpenView Windows simplifies this task by supplying 
the network map composed of graphics symbols that rep- 
resent the network components. Associated with each sym- 
bol is a network management application that is invoked 
when the particular symb(3l and a menu item arc selected. 
Thus, the network manager no longer needs to run an ap- 
piicatinn and then identify the network component of in- 
terest. Also, when a network manager is monitoring a net- 
work and the state of some network component changes, 
it is much faster for the network operator to identify the 
node having problems by looking at a network topology 
rather than having to look up a node name or address. 

In Fig. 2 the user wants to identify a computer system 
Delta (i.e.. get details on the machine type, version number, 
etc.], and so selects the en mp liter symbol labeled Delta and 
the Identify menu item under the monitor menu. After the 
user selects* the identify menu item, HP OpenView Windows 

*S0l«clioni Is accomplished by cllckjng the \^U mquse butfon on a uymbol or menu ilsm 
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passes the information to the application registered for that 
symbol type/menu item pair. The application then has con- 
trol, and can use HP Open View Windows routines to access 
the device or stored data to accomplish the actions as- 
sociated with Identify. In the exampie in Fig. 2, the applica- 
tion registered for the Delta computer system is NS Monitor, 
which is listed at the lop of the dialog box in Fig, 2b. If 
the user wanted to identify a bridge, a bridge symbol and 
then the Identify menu item would be selected. The article 
on page 66 describes how the HP Open View BridgeManager 
im.pl ements the Identify function. 



The map can be organized in any way the customer wants 
to view the network: physical, geographical or organiza- 
tional. For example, suppose a company has four computer 
systems — two in building 1 and two in building 2, and the 
two sites are connected via a LAN bridge. The user can 
draw a hierarchical map (Fig. 3) or a network model map 
[Fig. 4J, These examples also demonstrate that the user is 
not limited Jo placing a symbol in only one picture. In Fig. 
4 the subnet symbols BLDGIB and SLDG2B and the bridge 
symbol BRIDG8 ahow^ up in more than one display. BRIDGE 
represents the same physical bridge each time it appears. 
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The map functionality in HP Open View Windows allows 
the user to navigate through the map in many different 
ways. The user can double click on a subnet symbol to 
display the network that the subnet symbol represents, or 
the user can navigate through the map by using the follow- 
ing menu items contained in the map menu* 

■ Go To Top allows the user to view the top picture of any 
network currently being viewed. 

■ Go To Previous allows the user to view the previous picture 
displayed, 

• Go To Picture allows the user to view a picture listed in a 
dialog box. By clicking on one of the items in the box 
and then clicking OK on one of the the pictures listed, 
the selected item is displayed. 

■ Go To allows the user to find pictures containing the sym- 
bol for a selected node or device. A dialog box will be 
displayed listing all the pictures containing the symbol 
if the symbol is in more than one picture. 

Based on feedback from developers, two features were 
added to the map handling facility: treating lines as symbols 
and allowinji multiple applications to register for the same 
syniboL 



lines. In the early versions of HP OpenView Windows, 
many diiferent line ty^pes were defined, but they couldn't 
be managed like other network symbols. We discovered 
that many network management applications wanted to be 
able to manage lines. This was especially true of HP*s tele- 
communications divisions. Where the systems divisions 
thought in terms of boxes, the telecDmmunications divi- 
sions thought in terms of lines. 

Since we wanted the user interface to be useful to ail 
network management applications, lines w^ere made equal 
with other network component symbols. Lines can change 
color to reflect the status of the line. They can be named, 
registered for. selected, and managed. Lines can also be 
labeled and split into different internal types. For example, 
obi__iine can be split into line types obi_lfnei. Qbj_line2, and 
so on. This feature allows multiple applications that regis- 
ter for lines to coexist together. Witliout this feature, two 
applications tbat want to manage lines and use some of 
the same menu items would not be able to run in the same 
HP OpenView Windows together. The article on page 71 
provides an example of the use of HP OpenView Windows 
line types for network management. 
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Multiple Symbol Registration. Since more than one appli- 
cation can run at a time, more than one application may 
want to register for the same .syraboL This is especlaily 
true for applications that manage system symbols like HP 
DeskManageit SNA^ and TCP/IP. Therefore, we allow mul- 
tiple applications to register for [and to manage) the same 
symbol with the limitation that they cannot register for the 
same menu items. This means that if application A is regis- 
tered for the menu item/symbol combin<ition identify. DTC, 
application B cannot cannot register for this same combina- 
tion , but 11 can register for another menu item/DTC combi- 
nation. This limitation ensures that MP OpenView Win- 
dows knows to which application to send the selection 
message. Allowing multiple applications to register for one 
symbol also works well for integrating foreign applications 
thai need very different functionality. For example, an ap- 
plication that manages a computer system can run together 
with a terminal emulator connected to that system. When 
the user selects the computer sy.stem, the menu items for 
both the system management application and the terminal 
emulator can be enabled. 



Menu tntegration 

Customers buy network management solutions to gain 
increased u.se of network resource.'? and lower the t^ost of 
maintaining networks. Lower maintenance costs come 
through minimizing the time required to train operators 
and managers. Making the user interface as easy to use as 
[jossibie is one way of loivering the training costs. Another 
way of lowering training costs is tlirough the use of a con- 
sistent user interface across all network management appli- 
cations. This means that if a user is tracking down a network 
problem, there is no need to switch back and forth between 
different tools with different user interfaces lo accomplish 
the job. There are a wide variety of devices in a netw^ork 
that need to be diagnosed or configured, and if a user has 
to learn many different user interfaces for each device and 
type of activity performed, training becomes a significant 
cost to the customer; 

To help ensure a consistent user interface, HP OpenView 
Windows provides three types of menu items: standard HP 
OpenView Windows menu items, application dependent 
menu items, and application-added menu items. Standard 
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HP OpenView Windows menu items appear regardless of 
what applications are being used. The functionality^ of stan- 
dard HP OpenV^iew Windows menu items is always 
supplied by HP OpenView Windows, not by the applica- 
tion. The OVRun map menu items such as Go To Top and Go 
To Previous are examples of standard menu items. 

Application dependent menu items are displayed by HP 
OpenView Windows but rely on applications to provide 
functionality. They appear on the menu regardless of what 
applications have been installed. The Indenttfy menu item 
described earlier is an example of an application dependent 
menu item. As shown in Fig. 2 the functionality for Identify 
in this example is provided by the application NS Monitor. 

Application-added menu items are added by an application , 
and appear only when that application has been installed. 

Menu iiems may be object-specific or nonobiect-specific. 
Object -specific items remain disabled (greyed out) until 
the user selects a symbol in the map. If there is an applica- 
tion that provides the functionality for that type of symbol, 
it is enabled. An example of an object-specific menu item 
IS the Identify menu item, which is enabled only if an object 
to be identified has been selected. 

Nonobject-specific items are always enabled and can 
only be handled by one application. An example of a 
nonobject-specific menu item is the Show Alarms menu item. 
It is always enabled sirice the alarm list doesn't refer to 
any specific object. 

Status 

A graphical user interface allows the network operator 
to gain a large amount of information about a network from 
the components on the display. The use of color helps ihe 
operator absorb this information quickly. Color represent^ 
ing the state of network elements is a key part of HP Open- 
View Windows, 

When HP OpenView Windows is initialiiced the status 
of all of the devices is unknown. This slate is represented 
by the color blue. Once the applications .start coming up 
and informing HP OpenView Windows of the states of the 
devices, tlie colors are changed to represent the true stale 
of the devices. Red is used for critical yellow for warning, 
green for OK/normah and magenta for an informational 
state. The informational state mighl be used to indicate 
that the device is off-line or under test, or has messages 
queued that donH represenl a warning condition- If a device 
changes to a critical or warning state, in addition to chang- 
ing the color of the symbol, a warning message is displayed. 
Since lines are treated the same as symbols, their colors 
represenl I he same state information. The only difference 
is that the initial color for lines is black. 

Since HP OpenView Windows allows the user to have 
many different pictures representing different parts of a 
network, it is possible that the user may not be viewing 
the picture that contains a device whose status has just 
changed because the device may be at another level of the 
network hierarchy or on another network. One of the fea- 
tures of the HP OpenView Windows map is status propa- 
gation* This means if a symbol in a picture changes state 
(color) f all subnet symbols representing that picture will 
have their color changed to represent the highest severity 
contained in the picture. In the map examples shown in 



Figs. 3 and 4. if COMP1A had a critical error, the symbol 
COMP1A in the BtJ>G1A picture would be red. The subnet 
symbol BL0G1A in picture TOPA would also turn red, indi- 
cating to the user that at least one symbol in picture BLDG1 A 
had a critical severity^. Because the user may have multiple 
levels of subnets, status information must be propagated 
up through multiple levels. If the user had drawm the net- 
work in a network model map like the one in Fig. 4, this 
would mean that every subnet would be red. If C0MP18 
were critical (red). BLDGi B would be red because it contains 
C0MP1B, and 8IJ5G2B would be red because U contains sub- 
net symbol BLD61B. In HP OpenView Window^s» the user 
can configure the map to propagate status up one ievel or 
all levels. 

Help Facility 

The last area w^here HP OpenView Windows provides 
integration of applications is in the area of context sensitive 
help. The NewWave help facility^ is used to allow applica- 
tions to formal and integrate help text. The user is able to 
access the help facility by either pulling down the Help 
menu or by clicking on the Help button within a dialog box. 
The Help pull-down menu has menu items for HP OpenView 
Windows and lor each HP OpenView Windows application 
installed. Selecting a menu item under the Help menu brings 
up the index for HP OpenView Windows or the FiP Open- 
View Windows application. Clicking on the He[p button 
within a dialog box brings up the help screen for that dialog 
box. 

Conclusion 

HP OpenView Windows is a tool for both network man- 
agement application developers and end users. For de- 
velopers. HP OpenV^iew Windows simplifies the task of 
developing a graphical user interface for network manage- 
ment applications by providing functionality in the areas 
of map handling, menu integration, status* and help. End 
users also benefit from HP OpenView Windows, since the 
resulting applications have a consistent user interface that 
is easy to learn and use. 
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HP OpenView BridgeManager: Network 
Management for HP LAN Bridges 

Since LAN bridges receive all tlie data packets trarismitted 
on the LAN segments they interconnect, they are an ideal 
focaLpoInt for monitoring packet integrity and the number 
of packets fon/varded and filtered, 

by Andrew S. Fraley and Tamra L Perez 



As LOCAL AREA NETWORKS (LANs) grow to the 
limits of their physical and electrical specifications, 
traffic levels can reach a point where throughput is 
significantly impEiired. A LAN bridge logically separates 
segments of a ver^^ large LAN so that optimum throughput 
is maintained. A bridge allows intersegment communica- 
tion only as required. For example, if two nodes on the 
same LAN segment are communicating, there is no need 
for their packets to be forwarded to other LAN segments 
[see Fig. 1 ). Thus, a bridge restricts traffic to only the neces- 
sary LAN segments. 

To separate t.AN segments logically, a bridge monitors 
traffic on the network and builds an internal address table. 
In essence, the bridge learns the MAC addresses and port 
locations of nodes communicating on the LAN, and only 
forwards traffic to other LAN segments if source and desti- 
nation nodes are on different bridge ports. 

Recently, an IEEE 802.1 committee defined a standard 
spanning tree algorithm^ that allows redundant bridging 
to increase LAN reliability (see Fig. 2], A spanning tree 
algorithm is typically used to determine the shortest path 
between any two LAN nodes. The spanning tree standard 
adds the capability for two bridges to interconnect the same 
LAN segments and protect LAN operation in the event of 
a bridge fa i hire. The spanning tree standard places one 
bridge in active bridging mode for forwarding packets and 
the other bridge tn backup state for monitoring traffic and 
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maintaining its address table. It is important to note that 
connecting tw^o bridges tliat do not support the spanning 
tree standard could result in an infinite cycle of packets 
between redundant bridges. This would create an increase 
in the traffic levels on adjacent LAN segments, bringing 
down both segments. 

Hewlett-Packard byilds a number of two-port LAN 
bridges. These bridges interconnect IEEE 802.3 10-Mbit/s 
networks. IEEE 802.3 1-Mbit;s networks, and IEEE 802.5 
token ring networks. The HP products and the networks 
they support are given in Table L The lO-to-lO and 10-to-l 
bridges that bridge IEEE 802.3 10-Mbit/s and 1-Mbit/s net- 
works support the spanning tree algorithm and network 
management. 





Table 1 






HP LAN Bridges 




HP LAN 


Network Connection 


Network 


Bridge 




Management 


HP 2flE>47B Star- 


802.3 lO-Mbit/s to B02-3 


Yes 


LAN Brid^ft 


1-Mbit/s 




HP2864HBt^N 


802.3 10-Mbit/s to B02. 3 


Yes 


Bridge 


lOMbit/s 




HP 26649 A Token 


802.3 10-Mbil/s to 802.5 


No 


Ring Bridge 


4-Mbit/s 





Why Manage a Bridge? 

There are two reasons to manage a bridge: to monitor 
the network and to configure the bridge. Because bridges 
receive ail the data packets on the .segments they connect, 
they are an ideal local point for monitoring packet integrity 
and the number of packets forwarded and filtered. This 



LAN Briflge 



Fig. 1. How a LAN bridlgp isgfste^ traffic. 



Fig. 2. Redundant bridge configuration 
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informatiDB can be used to tune the network and isolate 
problems. For example, if a bridge port sees sustained traf- 
fic levels over twenty-five percent, this indicates that the 
segment may have too many nodes. Any subset in which 
the nodes generate a lot of traffic communicating among 
themselves should be broken inio a separate segments and 
isolated by a bridge. For another example, if a new node 
was added yesterday, and today the bridge port to which 
it is aUached is reporting a high level of CRC errors, this 
indicates a problem with the transmitter on the new node* 

Bridge management can also be used to customize the 
configuration of the bridge's operating parameters. For 
exam pie T if there is a set of nodes containing sensitive data 
that should be accessed only by a handful of privileged 
users, these sensitive nodes can he placed on a private 
segment and isolated by a bridge. The bridge's address 
table can be configured to forward only packets from the 
sensitive nodes and from the handful of privileged nodes. 
Consider a LAN that has grown so large that the worst-case 
forwarding time between two bridges exceeds a second. In 
this case, it might be necessaiy to adjust the spanning tree 
algorithm time-outs upward for optimal spanning tree per- 
formance. 

HP OpenVtew BridgeManager 

The HP OpenView SridgeManager is an HP Vectra com- 
puter-based HP OpenView application tliat manages HP's 
10-to-lO and 10-to-l LAN bridges. The BridgeManager pro- 
vides the ability to poll bridges, read parameters, set param- 
eters, upload and download complete configurations, log 
on and log off, log counters, and monitor alarms. The 
BridgeManager also supports the HP Ne^vWave help sys- 
tern, which has been integrated into the HP Open View- 
pro duct. 

The BridgeManager is divided into two parts: the user 
interface and the network interface. The user interface inter- 
acts with the HP OpenView system and Microsoft Win- 
dows. The network interface manages the communication 
with the LAN bridges. 

User Interface 

The BridgeManager user interface provides a graphical 
interface based on a network map consistent with other 
HP OpenView applications. About half of the BridgeMan- 
ager user interface code provides links to Microsoft Win- 
dows. HP OpenView Windows, and the BridgeManager 
network interface (see Fig. 3]. The other half of the user 
interface code implements a table-driven formatter that for- 
mats packets received from a bridge and parses user input 
into packets sent to a bridge. 

The parsing and formal ling functions were implemented 
in a central formatting mechanism for two main reasons: 
to reduce code size and to ensure flexibility. In Microsoft 
Windows, segments can be discarded or swapped from 
system memory and new segments loaded from disk. When 
Microsoft Windows runs low on system memory, ibis 
swapping or discarding begins to occur and performance 
degrades. Therefore, it is imperative to keep the size and 
number of code segments small The formatting mechanism 
meets the code size goal by trading off code size for data 
size. Instead of hard -co ding formatting statements for each 
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Rg. 3. Layers of software invofved in ffte HP OpenVfew 
BridgeManager apptication. 

packet t>T]e, the formatting directives are described in a 
data table and a shared formatter interprets the table. 

The network management protocol used by the 
BridgeManager is loosely based on an HP proprietary net- 
work management protocol that was targeted for use in 
HP's network management products until standard net- 
work protocols became available. 

Throughout the project, the BridgeManager protocol 
changed to add or delete functionality. The BridgeManager 
user interface was designed to minimize the time required 
to adapt to a changing protocol. The formatter achieves 
this flexibility goal because if the packet format is changed, 
no code is affected. Only the table must he modified to 
describe how to format and parse the modified packet. 

The formatting table is an array of field descriptors. A 
field descriptor contains information describing the field 
type (word, string, MAC address, etc.), the default, 
minimum, and maximum values for the field, the offset of 
the field in the result string, a pointer to the location of 
the field in the incoming packet buffer, and a flag that is 
TRUE if the field is the last field in the string being created 
(each siring may have multiple fields). The following frag- 
ment of a real formatting table describes the formatting of 
the \wn lines: 



1EEE802 Link Address 
Product NumE>er 



08f)009'0033C4 
HP 2864 7B 



contained in the list box of tlie BridgeManager Identify dialog 
box shown in Fig. 4. 
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struct 



h 



intfieldLtYpe; 



char*min_max_default; 



inl tield_offset; 



char "packet^location; 



intiasUiekl; 



counters = { 

FORM_RESSTR[NG, 

NULL, 

0, 



• Flag thai determines how the 7 
/' formatter handles thedata 7 

* identified by the packet */ 
/location fie W 7 
/•Pointerioaslnngcontainirrg 7 
/* i nf ormati on descri bi ng t he 7 
r bou nds of th e data Uelti 7 
' ' The character position of the 7 
.' formatted fteid in the output 7 
/"line 7 
/" A pointer to data in an incoming 7 
r packet or an iden ti f i e r 7 
/■ of a resource string */ 
rABooteanvariablethatistrue */ 
r if the c u rre nt f le I d j s the I asl */ 
/* field in theoutpul line 7 



/ " String from string table 
r No minmax informatfon 
r Field at beginning of line 



(char*) STRfNQJEEE_802_L^N^eADDR ESS, 

/* string table string 
FALSE, ," Not the iast string in line 



riDof^ 



7 
7 
7 

"/ 
7 



FORM^DDRESS. ■ " MAC address 7 

N U LL, / " No ml n. m ax i nf ormation 7 

23, /* Position 23 in line 7 

(char *) packet. ieee„802_source_addr, f* Data posrtJon 7 
.'*in packet */ 

TRUE, r Last field in line 7 



FORM_RESSTRING, ' String from string table 
NULL, /■ No min/max information 

0, ■'* F i eld at beg i n n i ng of 1 i n e 

(char*)STRING^PRODUCT,NUMBER, /" iDof string 

/*table string 
FALSE. r Not last field in line 



FORM^STRING, 
20," 
23, 



' String from packet 

■ Max length of string is 20 

'* Position 23 in line 



7 
7 
7 
V 
7 
7 

7 
7 
7 



(char * ) packet . prod uct_ nu mber , '* Data position in packet * ' 
TRUE TLastfieidinline 7 



Consider how this table is used to interpret an identify 
packet. The first field is of type FORM_RES STRING. Knowing 
the field is a resource string, the formatter interprets the 
packet-location pointer not as a pointer into a packet, bnt as 
a constant identifying which string is to be loaded from a 
Microsoft Windows resource string table. This string is 
loaded at offset in the result string. Because the iasUield 
Hag is FALSE, the formatter realizes that the resnlting string 
is not yet complete. The next field is of type FORMJVDDRESS. 
The formatter interprets the packet^location pointer as a 



pointer to a MAC address and formats the packet data into 
the string at offset 23 in the result string. Because the lasUield 
flag is TRUE, trailing spaces in the result string are trimmed 
and the string is output by the formatter to a list box or 
file [as directed by the code that invoked the formatter). 
The next field is another field of type FORM^RESSTRING. It 
is handled exactly like the first resource string field. The 
las! field is of type FORM_STR]NG. The formatter treats the 
packeUocation pointer as a pointer to a string. This Is the 
only field in the example whose min_ma)c_default string 
pointer is not NUIX. The "20 ' is scanned from the string and 
the formatter ensures that the string in the incoming packet 
is 20 characters or less. If longer than 20 characters, the 
string is truncated. The last_rfeld flag is TRUE so the second 
result string is trimmed and sent to a list box or file. The 
two result strings produce the two lines shown above. 

When the user wants to change parameters on a bridge, 
the formatter also takes strings that have been modified 
through interaction with (he user and parses them into 
outbound packets. The rest of the user interface deals with 
the network interface to send and receive packets ^ to inter- 
act with Microsoft Windows objects such as list boxes, edit 
fields, and pushbuttons, and to interface to the netw^ork 
map and the HP Open View C-tree data base. 

To illustrate how the BridgeManager user interface in- 
teracts with these three entities to implement a function, 
consider the Identify function. When thf3 user wishes to read 
identity information from a bridge, the user selects the 
bridge from which to reaci in the network map and then 
selects the Identity menu item in the Monitor menu. When the 
HP OpenView system detects that a bridge is selected, it 
sends a message to the BridgeManager*s message queue 
indicating that the Identify menu item was activated. The 
BridgeManager responds to this message by calling Micro- 
soft Windows to create and display the Identify dialog box. 

Each BridgeManager dialog box has an associated dialog 
box function that handles messages for that type of dialog 
box* When the Identify dialog box is displayed, Microsoft 
Window^s sends an initialization message to the dialog box 
function. When the Identify dialog box function receives the 
initialization message, it loads the selected bridge's text 
label and MAC addre.ss into the window's Bridge Label and 
Bridge Address fields shown in Fig. 4. To do this, the 
BridgeManager uses HP OpenView function calls to get an 
object identifier specifying which bridge was selected. The 
BridgeManager then uses this identifier to look up the 
bridge's label and MAC address by calling an H¥ OpenView 
function. The dialog box function then retrieves an identify 
packet from the selected bridge using the network interface* 
W^hen the packet is returned, the formatter formats the 
information into the list box for the user to view. 

Network Interface 

The most important function of the BridgeManager's net- 
work interface is to manage the communications exchange 
betw^een bridges and the management node. A management 
node is the system from w^hich a network manager uses 
the BridgeManager application to monitor a network. A 
large part of this functionality is devoted to the mainte- 
nance of incoming packets. 

Before beginning a discussion of internal packet manage* 
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ment, it is helpful to understand the architecture and gen- 
eral operation of the BndgeManager network conmionlca- 
tlon process. As shown in Fig. 3. the BridgeMsnager net- 
work interface resides in several layers of code. HP Of- 
ficeShare is HP's network transport software > The transport 
interface compatibility layer (TICL) in the HP OfficeShare 
software provides access to the network hardware via inter- 
rupts. The datagram laterface running on top of the HP 
OfficeShare software limits access to TICL as a protection 
mechanism. To send a packet across the network, the 
BridgeManager network interface makes a call to the data- 
gram interface, which filters down to a hardware transmis- 
sion request. When the network hardware receives a packet, 
it interrupts TICL. TICL then interrupts the upper layers 
of software until the packet reaches the destination appli- 
cation, which in this case is the BridgeManager, 

Recall from the discussion of the user interface that the 
Microsoft Windows memory manager dynamically swaps 
code and data segments. Interrupts from the net^vork 
hardware would fail if the network Interface code and data 
segments were allowed to move dynamically in memory. 
Therefore, the network interface is implemented as a static 
Microsoft Windows library that is separate from the user 
interface. The user interface must poll the network interface 
to receive any packets that may have arrived asynchro- 
nously^ When the network interface receives a poll request 



and has a packet availahle for the user interface, it copies 
the packet from its buffer structure into the pointer pro- 
vided by the user interface. The netw^ork interface then 
frees the packet buffer to accept another packet. 

Tw^o lypes of packets are received at the BridgeManager 
network interface: a response to a previously posted request 
packet (hereafter known as a response packet) or an event 
notification packet. Event notification packets arrive asyn- 
chronously. They are sent when the bridge detects a change 
in the network state that might be of concern to the user. 
Event notification and response packets coexist in the net- 
w^ork interface buffer structure. Therefore, an array is used 
to maintain four maximum-size EEEE 802.3 packets. Two 
of the array elements are used for response packets and 
the remainder for event notifications. The following is a 
code fragment containing the packet buffer declaration. 




Fig. 4, BndgeManager identify 
dmiog boXr 
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SifUCt I 



in I commandjd; 
Int buff ©restate; 



charpackeLbuffer 
11518] 
} receive Jjufferst 4 J ; 



/' T IC L J dent if ie r of rece i ve v 

/■ comm and posted to th fs buffer * / 
/' Per buffer Hag whidi can take on */ 
r values WAITING. EVENT, or 
RESPONSE V 



* Receive packet buffer 



7 



/' Al locate fou r receive buffer */ 
r structures (allowing applications '/ 
/" to buffer up to f o u r back - to-back * / 
/' packets) 



The network interface uses the buffer_state and ccmmand,id 
elements to control the packet buffer structure. The com- 
mand Jd element is returned from TICL and is used in the 
event that t fie receive request must be cancel ecL The buffer^ 
state element is used to determine whether a Ijuffer is wait- 
ing to receive a packet and also to maintain the balance of 
buffer use between event notification and response packets. 

It is critical that the incoming packet buffers not be filled 
with only response packets or only event notification pack- 
ets. If the network interface packet buffers were filled with 
response packets, event notification packets would be 
locked out of the management node, thus crippling fhe 
management feedback system. On the other hand, if the 
packet buffers were filled with event notification packets, 
the user would not receive responses to management com- 
mands issued on the network. To avoid this problem* the 
interrupt service routine responsible far vahdating and ac- 
cepting incoming packets is designed to monitor the state 
of tlie packet buffer with every packet arrival. Currently, 
two packets of either response or event notification type 
are allowed to coexist in the buffer structure- If two packets 
of the same type exist in the buffer and a third arrives, it 
will be thrown out to maintain the buffer balance. 

A major design goal of the BridgeManager was that it 
coexist with other management nodes and be a w^elhbe" 
haved application with respect tc CPU and memory use. 
The network interface library resides in static nonsw^appa- 
bie memory. Therefore, a major design goal was to keep 
the library as small as possible. The code size was not a 
problem, but the data structures, specifically the packet 
liuffer, were our major concern. During development, we 
determined that two buffers per packet type were more 
than sufficient to ensure that the network interface did not 
become a a performance bottleneck. However, if this con- 
dition changes in the future, the number of buffers for each 
type of packet is easily altered. A recompiiation is required 
to implement the change. 



Conclusion 

Bridges are important network components that segment 
local area networks into logical subnets* filter traffic be- 
tween subnets and the network segments, and add reliabil- 
ity to the network through redundant paths. Since a bridge 
observes network traffic during operation, adding manage- 
ment to bridges provides valuable network information to 
the user. 

Acknowfedg merits 

Special thanks to project manager Phill Magnuson, team* 
mates Ralph Bean and John Reilly , and the bridge hardware 
team. 

References 

1- LfxraJ At^q Nettvf>rk Standard - MAC Bridges, ANSI/IEEE Stan- 
dard P802.1D, Rev. 6, September 1988. 



70 HB/VLETT-PACKARD JOURISiAL APRIL 1990 



)Copr. 1949-1998 Hewlett-Packard Co. 



HP OpenView Data Line Monitor 

Monitoring targe and complex network configurations is 
crucial to maintaining the integrity and performance of data 
communication lines. The HP OpenView Data Line Monitor 
is a hardware and software solution for monitoring these 
data communication lines. 

by Michael S. Hurst 



INFORMATION NETWORKS are becoming larger and 
more complex and efficient management of these net- 
works is crucial as organizations become more depen- 
dent on them. At the heart of any network are the physical 
data communication links tliat connect the computers to- 
gether. For wide area networks these links often consist of 
point-to-point leased analog Hnes and it is problems with 
these lines that are the most common cause of trouble in 
data communications. Network managers and datacom 
managers in places such as corporate data centers are there- 
fore increasingly concerned with the performance and in- 
tegrity of their data communication lines. 

Point-to-point leased lines connect data equipment in 
separate locations. Normally four-wire lines with two cir- 
cuit pairs are used, one line for each direct ion of transmis- 
sion. Modems interface the data equipment to tliese lines. 
Imperfections that cause data errors on analog lines fall 
roughly into two groups: steady-state impairments (e.g., 
noise or amplitude modulation) and transient impairments 
[e.g., impulses or signal dropouts). In addition, telephone 
companies may condition lines to meet the attenuation 
distortion (frequency response) and delay distort ioo (en- 
velope or group delay) characteristics required by modern 
high-speed modems. 

The HP OpenView Data Line Monitor (OVDLM) is an 
analog leased-iine monitoring system for mu I ti vendor net- 
works, based on the HP 4948 A in-service transmission im- 
pairment measuring set (ITIMS).^ The HP 494SA permits 
the testing of Hnes while they are still in use. Conventional 
testing of analog lines requires the lines to he taken out of 
service while test signals, such as test tones, are applied. 
Alternatively, modem-based line monitoring and manage- 
ment systems are available from manufacturers of datacom 
equipment. However, these systems are usually proprietary 
aod may require specialized and expensive smart modems. 
The HP 494BA works with ordinary modems in the range 
of 2.4 to 14,4 kbits/s that are compatible with AT&T or 
CCITT standards. HP OpenView Data Line Monitor is com- 
patible with the other HP OpenView network management 
applications and can run concurrently with them. 

The HP OpenView Data Line Monitor software controls 
a single HP 4948A and one or more tCP 3777A channel 
selector access switches to monitor or troubleshoot analog 
datacom circuits at one location. Each HP 3 7 77 A switch 
can access up to 30 four-wire circuits and can be cascaded 
to achieve the required access capacity lo a maximum of 
31 switches. The functionality of OVDLM is provided en- 



tirely by the software miming in the HP OpenView work- 
station. Unlike some of the other HP OpenView applica- 
tions, OVDLM is not split into two parts, with one part 
running on a remote computer. Instead* the ITIMS and 
sw^itches are controlled directly from the HP OpenView^ 
workstation via the HP-IB (IEEE 488, lEC 625), The HP-IB 
has the advantage that its high speed enables the ITIMS 
and up to 13 access switches to be controlled from just one 
interface card in the PIP Vectra PO {Because of the electrical 
limit of 15 devices on one HP-IB. two interface cards are 
required for up to 27 switches, and three for the maximum 
of 31 switches). In many Installations it is possible that the 
HP OpenView workstation might be situated at some dis- 
tance from the communications rack where the ITIMS and 
switches are located. The distance limit of 20 meters with 
HP-IB cable can be overcome by using HP-IB extenders. A 
pair of HP 3 7204 A multipoint HP-IB extenders using fiber 
optic cable allows liPTB extension up to 1250 meters with 
negligible loss in performance. For greater distances, such 
as when the HP OpenView workstation and the ITIMS are 
at different sites, a pair of HP 37201 A HP-IB extenders can 
extend the HP-IB to unlimited distances over ordinary tele- 
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Fig. 1 . A typical equipment configuration tor using the HP 
OpenView Data Line Monitor (only one access switch, the HP 
3777 A channel selector, is showr}}. 
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Fig, 2. Screen used to enter trar^s- 

mission If mils. 



phone lines, albeit with a loss in performance. Fig. 1 shows 
a typical equipment configuration with one access switch. 

For routine alarm monitoring, 0\nDLM can be set to test 
all lines automatically m sequence. For troubleshootingp a 
single line can be selected and monitored continuously. 
This is particularly powerful for trapping intermittent 
faults. A description of all lines to be monitored is stored 
in the HP Open View Windows data base, including details 
of the modem t>^e and transmission performance limits. 
When OVDLM detects a problem with a particular line^ 
the color of that line is changed to red and a message is 
displayed in the HP Open View alarm window. OVDLM 
can report line performance in two ways* First, routine 
day-to-day monitoring typically uses an alarm-oniy mode, 
which indicates when any of the key analog parameters 
for each line go outside their predefined limits. Secondly, 
when data is required for iine performance benchmarks or 
trend analysiSt OVDLM is able to store the maximum, 
minimum, and average values of all line cbaracteristlcs 
during a selected measurement period. The results for each 
line are stored in a common log file which can be viewed 



at any time. 

Like all HP Op en View applications, OVDLM is divided 
into three programs: OVAdmin, OVDraw, and OVRun. The arti- 
cle on page 60 describes these programs. 

OVDLM and OVAdmin 

In OVAdmJn the user (a network or datacom manager) can 
define sets of transmission and conditioning limits. Trans- 
mission limits include specifications such as the minimum 
and maximum signal level, minimum signal-to-noise ratio, 
maximum number of dropouts allowed in a 15-minute in- 
tervah and so on. Conditioning limits define attenuation 
distortion and delay distortion masks. Typically these sets 
of limit values are based on AT&T or CCITT specifications 
for analog leased lines. Each set of limits is given a name, 
which is then used to specify the limits for a particular 
line, Many lines can thus share common sets of limits. The 
sets of limits are stored in a special OVDLM data file rather 
than the HP OpenView Windows data base. Where the data 
is stored is not apparent to the user. Fig. 2 shows the screen 
used to enter the transmission limits and Fig, 3 shows the 
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screeii used to enter the conditionmg limits. The data 
shown entered in Fig. 3 is the attenuation and group delay 
mask from CCITT recommendation NL1020 for interna- 
tional leased analog circuits. 

OVDLM and OVDraw 

In HP Open View Windows, lines diawn on the network 
map can be managed in the same way as computer or com- 
ponent icons. OVDLM registers with HP Open View Win- 
dows to manage these lines. In OVDraw the user draws the 
datacom lines on the network map. describes their detailSp 
and enters configuration information about the ITIMS and 
switches. Lines are described in exactly the same way as 
computer or component icons are described in other HP 
Open View applications, that is, the user selects the Descnbe 
menu item from the Edit menu, moves the pencil cmrsor 
over the line and clicks the mouse button. This brings up 
the line Describe dialog box. OVDLM extends the default 
line description of HP OpenView Windows to include de- 
tails of the line impedance, the modem type, and the names 
of the line transmission and conditioning limits (as set up 
in OVAdmin). Fig. 4 shows a sample netw^ork map with ri 



line Describe dialog box. Note that the modem t>^pe is set 
to AUTO. When this line is monitored in OVRun, the ITIMS 
will automatically search for the correct modem type by 
examining the live line signal. 

A difference between lines and most other managed ob- 
jects is that lines are passive because they need separate 
tools (the instruments] to do the management. The ITIMS 
and switches therefore have to be described in OVDraw. To 
accomplish this an Instruments menu was added to the OVDraw 
menu bar containing the Data L\r\e Monitor menu item. Select- 
ing this menu item will bring up an ITIMS Instruments dialog 
box on which the HP-IB interface select code and the ad- 
dress of the ITIMS and first-level switch can be entered 
[see Fig. 5), From this dialog box a Connect Lin© dialog box 
can be accessed for connecting lines to the ports of the 
first-level switch. A Connect Switch dialog box can also be 
selected for connecting a second level of switches to the 
first-level switch. Subsequently lines can be connected to 
the second-level switches. 

OVDLM and OVRyn 

'Hit* OVRun part of OVDLM controls the program^s 
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Fig. 6. Conirol dialog box with Line 
Scan menu item seiected. Alarms 
Only results, and 15-mfnute test 

intervals. 



monitoring activities. The user sets up global moniloring 
parameters and starts and stops the monitoring via a Cont^o^ 
dialog box accessed through a data line monitor menu ilem 
on the Control menu. The Set Parameters menu, which is a 
default menu item supplied by HP Open View Windows, is 
not used for this function because it requires a network 
line name to be selected first. Entering a line name wns 
found not to be intuitive for setting the global monitoring 
state because the global status information is not associated 
with any particular network line. 

The Control dialog box allows the monitoring state to be 
set to line scan mode or single-line mode, along with the 
required results and a test interval. The name of a disk file 
to hold the results can also be entered. Fig. 6 shows a Control 
dialog box with the Line Scan menu item selected, Atamis 
Only results, and a 15-minute test interval selected. The 
Results Type and Test Interval controls are greyed (dimmed) 
because they can only be altered when monitoring is 
paused. 

In line scan mode OVDLM will monitor each line in turn 
for a duration set by the test interval [5, 15, 30 or 60 min- 



utes). For example, if there are 30 4- wire circuits and a 
five-minute test interval is selected, a complete scan of all 
the circuits will take about six hours (assuming lioth the 
transmit and receive circuit pairs of each line are to be 
tested and allowing a minute per test for ITIMS training). 
If alarms-only results are selected, a summary of the impair- 
ment violations is wTitten to the results log file at the end 
of the test interval (C:\OV\GREECE in Fig. 6). If conditioning 
is selected as well as alarms only, the attenuation and delay 
results will be checked against the conditioning limits (see 
Fig, 3) and a pass/fail result will be written to the log file. 
If detail results are selected, the maximum, minimum, and 
average values of the steady-state line impairments, along 
with the number of transient events, are recorded at the 
end of the test interval. If conditioning and detail results 
are selected together, the complete attenuation and delay 
data is recorded as w^ell. 

In single-line mode OVDLM will continuously test only 
one line that has been selected on the network map. The 
Results Type selection works similarly to line scan mode» 
except that in Alarms Only, each individual violation is re- 




Fig. 7. An example of a current 
hne wndow. 
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Fig. 8. An example of a line con- 
dittoning window The deta for the 
upper-limtt mask comes from the 
defBy upper coiurnn m f\g. 3 ar^d 
the iower-iims! mask comes from 
the delay tower colarrtr) m Fig. 3, 



corded in the log file. This is useful for tracking down 
intermittents on a particular circuit. 

Once started, monitoring runs in the background even 
if all the OV^DLM dialog boxes have been closed and the 
user is working in another HP OpenVie%v Windows appli- 
catLon. Thus the user is not normally aware of the monitor- 
ing process. However, during HP-IB inpnt/output> the Vec- 
tra can appear busy for a few seconds, especially when 
reading back the line conditioning data from the ITIMS. 
This is because asynchronous tiP-lB input/output is not 
supported in tbe Microsoft Windows environment. To in- 
form the user when HP -IB input/output is in progress. 
OVDLM changes the cursor icon to an HP4B busy icon 
consisting of an hourglass and an HP-IB logo. At the end 
of the test interval the color of the line on the network map 
is changed to green if the measured performance is within 
limits and to red if it is outside one or more limits. In the 
latter case an alarm message is sent to the HP Open View 
Windows alarm window. 

During monitoriog the user can choose to view either 
real-time results for the line currently being tested or his- 
torical results for a line taken from the log file. These results 
are accessed through Current Line and Line History menu items 
on the Diagnose menu. 

Selecting the Cunent Line menu item will display a current 
line window and a line conditioning window. The current 
line window shows the steady-state and transient results 
and is refreshed from the ITIMS every twenty seconds. Any 
results that are outside the limits for the line are showm in 
red. The conditioning window displays a graph of attenu- 
ation versus frequency or delay versus frequency, using 
the ITIMS data-spectrum results and the conditioning mask 
limits for the line. This window is only refreshed every 
minute, the period with which the ITIMS remeasures the 
data spectrum ► Fig, 7 shows an example of a current line 
window. Here the impulse noise and retrains counts arc 
above limit and hence shown in red. As a result, the line 
on the map is also iurned red. Fig, 8 shows a sample line 
conditioning window. Note that the delay graph moves 
outside of the mask below^ about IDOO Hz. 

The Line History menu item allows browsing through the 



OVDLM log files for historical results of a particular Una. 
Filters are available to select the types of results required. 
For example, there are filters that can be used to narrow^ 
the selection to alarms results or details results for a particu- 
lar transmit or receive pair. 

Using Log Data 

It is important for datacom managers to track the long- 
term performance of their lines. The OVDLM log files are 
in ordinary ASCII text and organized so that they can be 
easily read by other application programs. For example, 
the data can be imported into a spreadsheet program^ such 
as Microsoft Excel, and trend analysis done on the detail 
results for each line. This trend analysis allows lines with 
deteriorating performance to be spotted before they become 
critical. Demonstration Excel macros to do this are supplied 
with the OVDLM software. 

Acknowledgments 

Acknowledgments are due John Duff, who designed and 
coded the OVDLM software, and Mark Dykes, Garry Irvine, 
and Elaine Butterwith for advice on many aspects of the 
definition and implementation of OVDLM. 

Reference 

1. N. Carder, el al., "In-Service Tran.smission Impairmfint T(>sting 
of Voice-Frequency Data Circuit^;' Mewleit-Pmikard Journal, Vul. 
38, no. 10, October 1987. 



MicTQSOll IS a U.S regssrored irademark of Mi^rosoU Corp 



APfWL imO HEWLEn-PACKARO JOUANAlTS 



)Copr. 1949-1998 Hewlett-Packard Co. 



Network Management for the HP 3000 
Datacom and Terminal Controller 

The HP OpenView DTC Manager software is responsibte 
for controlling, monitoring, and diagnosing tfie DTCs on a 
local area network. Its functions can be exercised eittier 
from a local workstation on the LAN or from an HP Response 
Center or other remote workstation, 

by Serge Y. Amar and Michele A. Prjeur 



A 



NEW GENERATION OF HP 3000 COMPUTERS was 
born in 1986, The distinctive features of tfiis gener- 
ation are HP Precision Architecture.^ the MPE XL 
operating system,^ and the input/nutpnt structure.^ 

One of the peculiarities of the input/nutput structure is 
the way terminals and printers are connected to a host HP 
3000 computer. They are connected through a controller 
(originally called the distributed terminal controller or 
DTC), which is connected to a local area network. Origi- 
nally, because the DTC code and configuration file were 
too big to fit in nonvolatile memory, the host was in charge 
of down loading them to the DTC at power-up. The host 
was also responsible for building the DTC configuration 
f i 1 e an d for managing the DTC [reset , upload , self -test , etc. ) . 

For the first release of ihe MPE XL snftwfire, the LAN 
was used more as an I'O bus than as a network, in the sense 
that a terminal plugged intn a DTC could establish a con- 
nection to one and only one host computer even if the LAN 
was shared by more than one host. Moreover, some impor- 
tant features were missing, such as wide area network ac- 
cess (X.25), 

With the release of the MPE XL 2.0 operating system in 
October 1989, major new functionalities are implemented 



in the DTC: X.25 access* PAD (packet assembler/disassem- 
bler) support, terminal I/O switched connections, back-to- 
back connections, and others. All of these services can be 
shared by multiple MPE XL systems connected to the LAN. 
In keeping with its expanded capabilities, the DTC has 
been renamed the daincom and term J no J con troJier. 

The DTC now offers LAN-accessible shared services, and 
is no longer tied to one host system. With the back-to-back 
feature, it can even work without any hosts on the LAN, 
For these reasons, a new way had to be found to manage 
the DTC and its services. This is the function of the HP 
OpenView DTC Manager workstation. 

The HP OpenView DTC Manager 

The HP OpenView t)TC Manager Is the network manage- 
ment software for the new services of the DTC. It is respon- 
sible for controlling, monitoring, and diagnosing the DTC. 

The HP Openview DTC Manager software runs on an HP 
Vectra ES/12 personal computer with a VGA display, a 
40'megabyte hard disk, an HP LAN access card, and a 2M- 
byte expansion board. It runs under the Microsoft Windows 
environment and the HP OpenView Windows umbrella. It 
implements a graphical user interface^ allowing the user 
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to trigger management hinctions on the local area nelwork 
DTC components. 

The contributions of the HP Open View ETTC Manager 
include: 

■ The use of HP Open View Windows to allow the user to 
"touch*' the network. 

■ Easy access to the DTC components through a graphic, 
logical view of the DTC rear panel. 

m Remote access to all of the DTC management fuoclions 
through a modem connection using the same graphic 
user interface. 

■ The ahility to add a support tool at any time without 
modifing the HP Open View DTC Manager code. 

HP Open View Windows is a network shell that mainly 
displays and manages graphic maps of networks. At initiali- 
zation, it spawns the applications that have an entry in the 
Open View Apps section of the WlN.fNI file (see article, page GO). 
It provides services such as map object management, menu 
and menu items addition, alarms, single-key data base ac- 
cess, and others. 

Almost all of the HP Open View DTC Manager's func- 
tions, triggered by the user from the HP OpenView network 
map. begin with the display of the DTC rear panel, which 
allows the user to see at a glance the types of cards and 
devices that are plugged into the DTC (Fig. 1]. Using the 
mouse, the user can easily select the part of the DTC on 
which to execute the management function. The selectable 
components are: the CPU board, a card (X. 2 5, direct connect 
card, modem connect card), a terminal, or a printer. Each 
of these is represented by a specific icon. 

All features of the HP OpenView DTC Manager can be 
accessed remotely through a 1200-baud or 2400-baud 
modem. The user interface is completely separate from the 
input/output functions so that it can be run in a remote PC 
without the need to pass graphic data through the serial 
modem link. This structure was chosen to optimize the 
exchange of information in the case of remote acces.s—^nly 
relevant binary data is transferrtid. A major problem of such 
a structure is that it is not possible to take advantage of 
some Microsoft Windows features. For example, a list box 
can contain more information than can he transferred all 
at once over the serial link to load the list box. Therefore, 
the HP OpenView DTC Manager handles the scroll bars of 
list boxes to navigate through the lists, and only list data 
to be displayed is transferred. 

Hooks have bet^n implemented in the HP OpenView DTC 
Manager so that a DTC support tool can be added at initiali- 
zation time, using the DtcManagerApp section in the WINJNI 
file. For example, if a dump formatter were implemented 
following the guidelines, it would be able to take full advan- 
tage of the remote access capability of the HP OpenView 
DTC Manager. 

Software Structure 

The HP (JpenView DTC Manager consists of four Micro* 

soft Windows components (Fig. 2): 

m PCMPRMP. This module is responsible far interfacing 
with the HP OfficeShare driver and implementing the 
two management protocols MP and RMP. ' 

m DTCMGRIO. This module is responsible for maintaining 
the data base associated with DTC management and for 
translating requests cuiniug from the user interface to 



requests that can be understood by the PCMPR\tP mod- 
ule. 11 is also responsible for deciding whether a down- 
load request coming from a DTC must be serviced or 
rejected, 
a DTCMGRUL This module is responsihte for handling 
the user interface — for example, interpreting requests 
coming from the user, requesting additional information 
when needed, and displaying the results of the requests, 
a RLS/CA. This module has ^wo parts. RL Switch is respon- 
sible for managing the local and remote modes and for 
switching messages between DTCMGRIO and DTCMGRUI 
either on the same PC or tlirough a serial modem link. 
Data is never exchanged directly between DTCMGRUI 
and DTCMGRIO. CA stands for connect application. It 
is responsible for the logon and logoff process m both 
local and remote modes. 

Two of these modules, DTCMGRUI and RLS/CA. are HP 
OpenView Windows applications. An HP OpenView Win- 
dows application is, first of all, a Microsoft Windows appli* 
cationt that iSt it hasa WinMain. which performs initialization 
and implements the GetMessage/ Dispatch Message loop. How- 
ever, during the initialization process, it must call some 
HP OpenView intrinsics, and it does not create its own 
main window. The application's main window is created 
by HP OpenView Windows and acts as a conmiunication 
window between HP OpenView Windows and the applica- 
tion. The application must provide the window procedure 
for this communication window. 

Because an HP OpenView Windows application has no 
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Fig. 2. The HP OpenView DTC Manager consists of four Mi- 
cFosott Windows components: PCMPRMP (protocol control- 
ler), DTCMGRIO (data base manager and translator), 
DTCMGRUI (user tnterface), and RLS/CA (comniunicatson 
and logon). 
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main window of its own, it has no menu bars. Instead, it 
requests HP Open View Windows to add menu items to the 
main HP Open View Windows menu bar. An HP Open View 
application has to provide for the processing of all the 
menu items it has registered, and for the processing of some 
HP Op en View general messages. 

User Interface Structure 

The structure of the user interface module [DTCMGRUl) 
is highly modular (see Fig. 3). It is based on the property 
of Microsoft Windows that once created, a window is an 
independent entity able to receive and process its ow^n 
messages transparently to the process that has created it. 

DTCMGRUl consists of a main window and a series of 
child windows. The main window is the communication 
window created by HP Open View Window^s during initiali- 
zation of the application- It is an invisible window and it 
is mainly dedicated to receiving messages coming from HP 
Open View Windows. When the user selects a function 
managed by the application, HP Open View Windows sends 
a message to the communication window. 

The window procedure of the communication window 
is just a dispatcher that creates child windows of the re- 
quested class. These are invisible child windows, shown 
as level 1 windows in Fig. 3. Once it has created the right 
level 1 child window, the communication window proce- 
dure sends it a trigger. Then, it no longer w^orries about 
the requested function since it will be processed by the 
created child window. The communication window sim- 
ply waits for the Don© message sent back by the child win- 
dow, and then destroys the child window, since this means 
that the requested function is completed. Every child win- 
dow^ is a function of a certain type. For example, there are 
child windows of type Configure, Set Parameters, Upload DTC, 
and so on. 



Level 1 child windows are only created and destroyed 
by the main level. Although a child window could destroy 
itself, for consistency this is never done in DTCMGRUL 
The main level is always aware of what is active below it. 

In a similar manner, level 1 child windows can create 
invisible level 2 child w^indows, which are independent 
entities for Independent subf unctions. Level 1 child win- 
dows can also create visible level 2 child windows, which 
are dialog boxes. Dialog boxes can also be created by invis- 
ible level 2 child windows. 

One of the main differences between an invisible child 
window and a dialog box is that an invisible child window 
is destroyed by its parent, whereas a dialog box destroys 
itself. Moreovern an invisible child window, when it has 
completed its function, sends a predefined message to its 
parent. A dialog box child window, when it is created, 
receives as a parameter the message it must send back to 
its parent once it has completed its function. Dialog boxes 
do not have predefined completion messages. 

Each of the child windows ^ either invisible or visible, is 
able to communicate with DTCMGRIO through the RL 
Switch module without the help of the communication 
window by giving its own handle in any DTCMGRIO re- 
quest. 

Remote Access Structure 

One of the objectives for the HP OpenView DTC Manager 
was remote access to network managemenl applications. 
Two PCs with modems running the HP OpenView DTC 
Manager can communicate and the same DTC management 
capability is available at both (Fig. 4), For example, from 
an HP Response Center PC, an HP engineer cdn manage a 
customer s DTCs, In fact, only the user interface (DTCMGRUl) 
and RL Switch run on the Response Center PC. Commands 
are sent to the DTCMGRIO module of the customer's PC 
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Fig. 3. Structure of the user interface module DTCI\4GRUi. 
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through the serial link. 

This functionality is implemented in RL Sivitcb, which 
is able to switch from local to remote mode and to send 
orders and replies between DTCMGRLTl and DTCMGRIO 
either locally \\ithin the same PC or remoEely over the 
modem line (Fig, 5), 

The user is able to log on locally or remotely using the 
connect application* CA. At initialization, this module 
adds four menu items to the control menu of HP OpenVie%v 
Windows: Logon* Logoff, Remote Connect, and Remote Di&ODonect. 

When Logon is activated , Remote Connect and Remote Discon- 
nect become inactive. When Remote Connect Is activated, both 
logon and Logoff are inactive. Finally, when the user is 
neither locally logged on nor remotely connected, both 
Logon and Remote Connect are enabled. 

When a user at the Response Center PC chooses the Re- 
mote Connect menu item, the DTCMGRUl module in the 
Response Center PC receives the following sequence of 
messages: 

RLPREPAREFORCONNECTwrth param = 
RESPONSE_CENTER„PC 

RL.LOGONSTATUS 

On the first message, DTCMGRUl just stores the fact that 
it is no longer in local mode but not yet in remote mode. 
On the second message. DTCMGRUl stores the fact that 
remote mode is now active. All HP OpenView fTrC Man- 
ager menu items are enabled and the inactivity timer is 
started. 

The DTCMGRUl module located in the customer PC re- 
ceives only the message Rt^PREPAREFORCONNECTwfthparam 
= CUSTOMER. PC. Ihis message is ignored. 

Thereafter, except for some very rare cases, whether the 
HP OpenView DTC Manager is working in remote or local 
mode is absohitely transparent to DTCMGRUL There are 
only two exceptions. First, the display of the Function In 
Progress dlaloj^ box depends on the mode for some ref]iiests 
to DTCMGRIO. Second, in the dialog boxes of type OpenView 
DTC Manager List, when the items are read one after another 
and the HP OtienView DTC Manager is in local mode, the 
items are displayed only when the list box is full to avoid 
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Fig. 4. The HP OpenView DTC manager aifows remote ac- 
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dickering effects. In remote mode they are displayed im- 
mediately. 

A remote connection is closed if (1) the Response Center 
engineer completes the job and activates the Remote Dfscon- 
nect function, [2] the customer requests that the connection 
be aborted, or [3] the connection between the tvx^o modems 
breaks. In case (1). DTCMCRUI receives RL_LOGOFF BEQUEST 
from RL Switch, and then RUREMOTECONNECTCLOSED. In 
cases (2) and (3], DTCMGRUl receives only RL_REMOTECON' 
NECTCLOSED. On RL_LOGOFFREQUEST, DTCMGRUl is free 
to accept or reject the logoff. If no function is active, the 
logoff is accepted. If any function is acti%^eH the ksgoff is 
rejected and the remote disconnect procedure is inter- 
rupted. On RL_REMOTECONNECTCLOSED. any active func- 
tion is aborted and DTCMGRUl assumes that its new status 
is local and logged off. 

Figs. 6f 7t and 8 show the sequence of messages ex- 
changed between CA, RL Switch, and DTCMGRUl in the 
cases of a remote logon, a remote logoff , and a customer- 
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Fig, 6. Messages exchanged for 3 remote logon. 

forced abort or a modem line failure. 

Dialog Boxes 

Microsoft Windows provides two types of dialog boxes: 
modal and modeless. Modal dialog boxes do not allow the 
application [here DTCMGRUI) to do any processing except 
for handling the dialog box, while modeless dialog boxes 
allow the application to process both the dialog box and 
other application windows concurrently. 

In compliance with the HP OpenVieiv Application Style 
Guide, all dialog boxes in DTCMGRUI are modeless dialog 
boxes. Modeless dialog boxes consume less stack space 
than modal boxes. They behave as standard child window^s 
and are more bug-free than modal boxes. However, the FIP 
OpenView DTC Manager often needs modal behavior. For 
example, when a dialog box is displayed, the user is not 
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allowed to do anything except enter information in the 
box. To meet this need, modal behavior is simulated by 
creating a modeless dialog box and disabling the window 
that ha,s created it. 

The modeless dialog boxes inside DTCMGRUI can be 
classified into three categories: classical, HP OpenView 
DTC Manager lists ^ and backplane. 

The classical dialog boxes are normal Microsoft Win- 
dows dialog boxes* They implement list boxes, radio and 
check buttons, edit fields, and so on. All of these controls 
are handled by Microsoft Windows after the dialog box is 
created and initialized, Most of the dialog boxes fall into 
this category. 

HP OpenView DTC Manager lists are dialog boxes that 
contain list boxes handled by DTCMRGUI instead of Micro- 
soft Windows. These list boxes are initialized with 1 3 items 
and are always reset and reinitialized with 13 items 
maximum. The scroll bar on the right side of the list box 
is not part of It, but is a scroll bar control handled by the 
dialog box as an independent scroll bar. The items in the,se 
lists are not stored in memory by DTCMGRUI but are re- 
quested one by one from DTCMGRIO through RL Switch. 
Every time the user wants to add, delete, or modify an item 
or scroll up or down the list, the whole list is reset and 
orders are sent to DTCMGRIO to reread the displayed part 
item by item [Fig. 9]. This mechanism is used because each 
record in the list may be quite long and lists may have 
many records, so the amount of memory required to load 
ail the items at once in memory and to have Microsoft 
Windows handle the list would be too large. Moreover, in 
remote mode, if the amount of information requested at 
one time is too large, the time between the start of afunction 
and the function's actually becoming active would be too 
long- With this principle, in remote modej each item is 
displayed as soon as it arrives, so it seems to be faster, and 
in any event, a maximum of 13 items will be transferred 
even if the list is 512 items long. 

Support Tool Integration 

Support engineers sometimes need to run special appli- 
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cations — for example, a light formatter ^or the dump files 
comiag from the DTC. These applications must be inte- 
grated into the HP Open View DTC Manager, even though 
they were not defined at the time the HP Open View DTC 
Manager code was written. To accommodate this need, 
hooks were implemented in DTCMGRUI and DTCMGRIO 
so that these applications can be added d\Tiam.icaily and 
integrated into the HP Open View DTC Manager. 

Except for some special procednres during initialization 
and shutdown, a DTC Manager application is a normal 
Microsoft Windows appUcation that doesn't need to deal 
mth HP Open View Windows. Like the DTC Manager. 1!)TC 
Manager applications are structured in two parts, one for 
the user interface and one for everything dealing with the 
files and the DTC [the second part is referred to here as 
the I/O part of the application). This allows them to be 
used in remote mode as ivell. 

The structure of the solution is showm in Fig. 10. The 
DTC Manager application is accessed through a menu in 
the Tools subsection of the HP Open View main menu. The 
Tools menu and its submenus are added by DTCMGRUl 
during the initialization phase w^hen the DicManagerApp sec- 
tion is found in the WJNJNt file. 

When the DTC Manager tool (or application) needs to be 
used, the user selects the application from the Tools menu, 
DTCMGRUl receives the request from HP Open View Win- 
dows and sends a message to DTCMGRiO requesting it to 
spawn the 1/0 part of the application. AH HP OpenView 
DTC Manager menu items are grayed. DTCMGRIO spawns 
the I/O part of the application, passes the RL Switch win- 
dow handle to it, and replies to DTCMGRUl that the spawn- 
ing was successfuL With the reply, it sends the handle of 
the I/O part of the application. 

DTCMGRUl spawns the user interface part of the appli- 
cation and passes to it the handle of the I/O part of the 
application and the handle of RL Switch. The modules of 
the appHcation can now exchange messages directly 
through RL Switch using the RL_SENDDATA message. 



When the application is no longer needed, the user 
selects a close function in the user interface part of the 
appUcation, which notifies DTCMGRUl that it wants to 
quit. It does not quit yet. DTCMGRUl sends a request to 
DTCMGRIO to kill the 1/0 part of the application. 
DTCMGRIO kills the L'O part of the application and notifies 
DTCMGRUl. DTCMGRUl then kills the user interface part 
of the application and reenahles the HP OpenView^ DTC 
Manager menu items. 

The advantages of diis solution are: 

■ The DTC Manager application modules are Microsoft 
Windows modules, not HP OpenView Windows mod- 
ules. The DTC Manager application menu item will ap- 
pear only if the W[NJNI file contains a DtcManagerApp sec- 
tion. 

■ The DTC Manager application code Is loaded only when 
needed, so no memory is allocated to it while the HP 
OpenView DTC Manager is processing a management 
function, 

■ The DTC Manager applications don't have to deal with 
HP OpenView^ Windows, so they are independent of HP 
OpenView Windows and HP OpenView DTC Manager 
releases. 

The DtcManagerApp section of the WINJNI file has the fol- 
lowing syntax: 

[DtcManagerApp] 

App1 = Applil . APPUI.EXE, APPIO.EXE 

where Appi is the name of the DTC Manager application, 
ApplJ! is the name of the menu item to be added to ihe Tools 
menu, and APPULEXE and APP10.EXE ore the names of the 
application's EXE modules. It is mandatory for these files 
to be in the subdirectory EXE of the DTC Manager data 
base. During the initialization process. DTCMGRUl looks 
in the WlN.tNl file for the DtcManagerApp section. If it exists, 
the Tools menu is added to the HP OpenView menu bar. 
For each valid entry in this section, DTCMGRUl adds the 
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carrespnnding menu item in the Toofs menu. 

HP OpenView DTC Manager Data Base 

The HP OpenView DTC Manager does not use the file 
access facility provided by HP OpenView Windows for 
three reasons. First of all, the file access faciHty provides 
singie-key indexed file access and the HP OpenView DTC 
Manager would have needed multikey access. Second, the 
configuration data for a DTC can be very large and retrieving 
it via HP OpenView file access would have drastically 
slowed the initiahzation of a remote access If the user 
chooses to transfer the HP Open View network topology map. 
Final ly^ not using HP OpenView file access means that the 
DTCMGRIO and PCMPRMP modules can be Microsoft 
Windows appl teal ions and not HP OpenView Windows 
applications, so that even if HP OpenView Windows is 
inactive, they are always active and ready to receive DTC 
events and service DTC download and upload requests. 
This allows the user to free memory by closing HP Open- 
View Windows to run another Microsoft Window^s applica- 
tion while the PC continues to serve DTC-triggered manage- 
ment functions. 

The HP OpenView DTC Manager data base takes advan- 
tage of the MS-DOS*' directory hierarchical structure antl 
stores data within a tree of subdirectories of the DTCMGR 
directory. The DTCMGR directory with its subdirectory tree 
is created at installation time in the directory specified by 
the user; the default is the root directory. The user may 
not specify more than one level of directory — for example. 
CaMYDIR. in this case the data base will be installed in 
C;MVIYOIR\DTCMGR. 

The following list illustrates a typical HP OpenView DTC 
Manager data base containing a DTC named DTCNAME on 
the HP OpenView^ map, loaded wilh two serial interface 
cards in slots and 1, one X.Z5 card in slot 4, and slots 2, 
3, and 5 empty. The DTC code and configuration have been 
downloaded and X.25 protocol has been started on the 
X.25 card but the PAD support protocol has not In this 
list, lowercase is used for files and uppercase for direc- 
tories: 
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the HP OpenView DTC Manager, 



,ADTCMGR\mape02 
\acclist 
\copyhdr 
\DTCNAME.DTCMCONF$:sglobal 

\j3ackplan 
\SLOT0\tioconf 
\SLOT1\tiocoof 
\SL0T4\I123 

^witinfo 
\stsinout 
\p3dinsec 
\padaGc 
^padswit 
\DTCNAME.DTO.$DWLDS^.gJobal 

gJobhdr 

jDackplan 

^SLOT0\tio<Mnt 

\SLOT1\tlocont 

\SLOT4\h23 

\swjtmfo 
\stsinout 
.DEFAULT vcpudef 
\terrTi.def 
\printer.def 
\host,def 
gtobhdr.def 
vacdist.def 
.DC\struct.def 
\MOOEM^Btruct.def 
\X25\l123.def 
^^tsswit.def 
\stsinoL(t.def 
\padswit.def 
xpadacc def 
^padinsec.def 
\COPY 
\MONfTOR 
\UPLOAD 
^CODE 
\EXE 

The file map802 contains one entry per configured DTC 
containing: the DTC name (e.g., OTCNAME), the DTC's cur- 
rent LAN [IEEE 802.3) address, the downloaded LAN ad- 
dress, and the DTC's LAN node name. It is updated and 
used by the DTCMGRIO module. Each time a DTC Is 
created, its HP OpenView map name is written in this file 
with the two LAN addre.'^ses equal to D, When the user 
saves a configuration, DTCMGRIO get.H the LAN address 
contained in the DTC GPU configuration and puts it in the 
current LAN address in the mapS02 file. When the DTC 
requests a download, DTCMGRIO copies the current LAN 
address into the downloaded LAN address. 

The file acdist is the security list file, w^hich is down- 
loaded to all the configured DTCs. 

The DTCNAME.DTC subdirectories contain the DTC config- 
uration data. They descrilie a DTC and consist of up to 
three subdirectories: SCONF$, SCONFSTP, and SDWLDS. 

The SCO NFS subdirectory contains the DTC off-line con- 
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figuration files. This configuration will be douTiloaded mto 
the DTC on the next download operation. The contents of 
this directon' and its associated snbdi rectories are modified 
when the user selects the Configure menu item. The SCONFS 
subdimctor\' consists of tiuee files and several subdirec- 
tories, one for each configured card of the DTC- The file 
backptan stores the information needed to display the back- 
plane of a DTC It contains 56 bytes: 

■ Byte 0: DTC Type. This is for future use. if we need to 
distinguish between multiple types of DTC. 

■ Byte 1: Verif>' Flag. Indicates whether the configuration 
associated with this backplane has been verified. 

■ Six records of 9 bytes each, one record per card. Record 
is for card 0. and so on. Each record ixmtains the card 
type (empty, direct connect, modem connect, or X.25], 
and the port types (terminai, printer, or host) for ports 
to 7. 

The file global contains the configuration of the CPU board 
[node name, IP address- logging classes, user prompt, wel- 
come message]. The file globhdr contains the LAN address 
of the DTC. 

Each configured card has a SLOTx subdirectory, where x 
is the card number (from to 5]. The files contained in 
each SLOTx subdirectory completely describe the card. The 
number of files and their contents depend on the card type. 
If the card is an 8-port direct connect card, its SLOTx suh- 
di rectory contains the file tiocont, which stores the config- 
urations of ports to 7. If it is a 6-port modem connect 
card, its SLOTx subdirectory contains the file tioconf, which 
stores the configurations of ports to 5 and two dummy 
configuration blocks. If the card is an X.25 card, its SLOTx 
su?Kli reef Dry contains six files: 

■ 1123 stores level 1, level 2. and level 3 configuration data 
and the permanent virtual circuit list used by X.25. 

■ switjnto is a list that stores the ho.^t resolution table (sys- 
tera-to-system switching information) used by X,25. 

■ stainout is a list that stores ihe LUG table (system-to-syslem 
local user group) used by X.25. 

■ padinsec is a list that stores the PAD security table [PAD 
incoming security! used by PAD support. 

■ padacc is a list that stores the PAD device table (PAD 
access] used by PAD support, 

■ padswit is a list that stores the PAD switching table (DTC 
PAD switching information) used by PAD support. 
The $CONF$ JP subdirectory contains the temporary con- 
figuration files. 'I*his directory is used for temporary storage 
of the modifications when the user is in the off-line config- 
u rat ton function. The SCONFS.TP subdirectory is created by 
DTCMCRIO when the user starts modifying a DTC config- 
uration. It has the same .structure as the $CONF$ subdirec- 
tory. 

The SOWLDS subdirectory contains the downloaded con- 
figuration files. This is the image of the DTC configuration 
data. This set of files is updated during dynamic configura- 
tion functions. The SDWLDS subdirectory is created by 
DTCMCRIO when the user creates a new DTC. LJpon suc- 
cessful completion of a download operation DTCMCRIO 
will copy files from the $CONF$ directory into the $DWLD$ 
di rectory » which keeps an exact image of the configuration 
data downloaded to the DTC, When dynamic changes are 
done using the Set Parameters menu item, only the data con- 



tained in this directory is updated unless the user requests 
that the modifications be copied to the off-line configura- 
tion as welL 

The COPY subdirecton^ is created by DTCMCRIO when 
the user selects the COPY function (in the configuration 
menu] for the first time. Thereafter, it is never removed, 
allowing the user to make several copies of the same item 
using the PASTE function. The file , DTCMGRcopyhdr con- 
tains the type of item copied. The ty^pe can be DTC (the 
entire DTC configuration), SIC-OC (direct connect card], S!C- 
Modeim (modem connect card]. SSIC (X.25 configuration), 
Term [terminal configuration). Printer^ or Host. This file is 
checked when the PASTE function is executed* since the 
COPY action and the PASTE action must be consistent. Then, 
according to the type of item, the subdirectonr^ COPY is 
filled with al] or part of a SCONFS subdirectory. 

The DEFAULT subdirectory contains all the default values 
for the configuration of a DTC. It has three subdirectories — 
DC, MODEM, and X25 — and six default files, which contain 
the default configurations of each type of card in the DTC. 
The DC and MODEM subdirectories both have a file called 
struct def {9 bytes), which contains the default structure for 
each card type and port type. The X25 subdirectory contains 
the default files to be used for an X-25 card. 

The UPLOAD subdirectory receives the files containing 
upload data. These files are named depending on what 
kind of upload data they contain. DTCNAME and HOSTNAME 
are the names used by the user on the HP Open View map. 

The MONrrOR subdirectory^ contains event logging files 
and trace files. 

The CODE subdirectory contains the code files to be 
downloaded to the DTC. 

The EXE subdirectory contains all the executable files of 
the HP Open View DTC Manager and some support tools. 

Memory Organization 

The PC memory organization was one of the most dlf- 
ficull c:hallenges of this project. The goal wiis tu have the 
HP OpenView DTC Manager run on an HP VectrH KS/12 
personal computer equipped with a 2M-byte additional 
memory board (the HP 4 5 944 A Vectra ES expanded mem* 
ory card*^). 

Microsoft Windows can rim in two different modes: large 
frame or small hame. In small frame mode» the memory 
area from C8000 to EFFFF is used to map expanded mem- 
ory. The data segments of Windows applications. Windows 
libraries, and appH cations' dynamic libraries are loaded 
into conventional memory* that is, below 640K. This op- 
timizes the use of expanded memory, but it uses a large 
amount of the shareable memory and minim i7;es the paral- 
lelism of applications. 

In large frame mode, Microsoft Window^s sets what is 
called a bank line, specifying how much space will be used 
in the 256K4o-64f)K slot for expanded memory mapping. 
Once this line is chose n* everything below the line [from 
to the line) is considered shareable memory (called non- 
bankable memory. below-the-!ine memory, or global mem- 
ory]. Elverything above the line (from the line to 640K) is 
used for page banking (called bankable memory or above- 
the-line memory). In this model the applications' data seg- 
ments and dynamic libraries and the Windows libraries 
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are banked, meaning that they are loaded in expanded 
memory. 

The advantage of running in large frame mode is that it 
frees a lot of the cionventional memory, thereby increasing 
the parallelism of applications. The disadvejntagc is that it 
uses a lot of expanded memory because Microsoft Windows 
dupUcates some Windows library segments in every bank 
and the smallest application will take no less than 11 2K 
bytes of expanded memo^>^ Moreover, when an application 
needs more pages, Microsoft Windows will allocate pages 
to this application until it reaches the maximum number 
of pages that can be banked simultaneously. Thereafter, 
Microsoft Windows is not able to free these pages for other 
applications. 

Code and resources (dialog box descriptions, text, etc.) 
are always hanked in expanded memory whatever the 
mode. 

The HP Open View DTC Manager needs Microsoft Win- 
dows to start in large frame mode, because in small frame 
mode it runs out of global memory. Depending on the mem- 
ory setting of the PC, Microsoft Windaws/286 2.1 decides 
at start time in which mode it is going to run. LSome of the 
criteria are: 

■ The amount of conventional memory left when Microsoft 
Windows is started. This depends on how many drivers 
are present and whether HIMEW is in use (the HIMEM driver 
saves 64K bj^es of conventional memory). 

■ The version of the expansion memory driver available. 
This should be KMS 4,0 to he in large frame mode. 

■ The type of expansion board used. It should support 
EMS 4;0 to be in large frame mode, 

■ The amount of expanded memory available. 

■ Whether backfilling is in use. It should be in use to be 
in large frame mode. Backfilling is the ability to replace 
the upper 256 or 51 2K bytes of the CPU memory by an 
equivalent amount on the expansion memory board. This 
is mandatory to enable w^indo%vs to set the bank line 
(also called the EMS line) below 640K bytes, hi this 
situation, the memory from to the EMS line is con- 
sidered to be shared, and the memory from the EMS line 
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to 640K is used to bank expanded memory. 

Talcing all these parameters into account, the memory 
organization shown in Fig, 11 allows the HP Open View 
DTC Manager to run correctly. 

Summary 

A new generation of HP 3000 computers needed a new 
generation of network managenient. The HP Open View 
DTC Manager provides easy-to-use graphical interfaces, al- 
lowing the user to have comprehensive knowledge of the 
network and its components. 

The important new shared services provided by the DTC 
also needed a management station that was independent 
of the host. The HP Open View DTC Manager workstation 
provides this. However, a host may continue to manage a 
DTC when it is not necessary to share its services. 
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Fig. 1 1 , HP Vectra ES personal computer memory map for 
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M HEWLETT-PACKARD JOURNAL APRtL 1990 



)Copr. 1949-1998 Hewlett-Packard Co. 



Developing a Distributed Network 
IVIanagement Application Using HP 
OpenView Windows 

Using concepts from the HP OpenView architecture and 
the facilities provided by IHP Openview Windows, nefwor/c 
managennent services and distributed applications were 
developed for user feedback and validation of the 
architecture. 

by Atuf R. Garg and Lisa M. Cofe 



THE HP OPENVIEW NETWORK SERVICES MONITOR 
(OV/NS Monitor) provides network management 
functions for distributed HP 3000 computers. OV/NS 
Monitor is divided into two parts: the uidln application 
and the user interface. The main application resides on an 
HP 3000 computer that is designated as a management 
node and the user interface resides on an HP Vectra per- 
sonal computer. The main appUcation performs network 
management functions via the software residing on the HP 



3000 computers designated as managed nodes. OV/NS 
Monitor is for interna] use only and is not available as a 
product. 

This article describes I he approach used to develop the 
OV/NS Monitor network management apjilication using 
some of the coricepts from the HP OpenView architecture 
and the facilities provided by the HP OpenView Windows 
software. Many of the ideas and concepts used in develop- 
ing this application are being incorporated in the develop- 
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Fig. 1. The main components of 

the HP OpenView Network Ser- 
wees Monitor (OVINS Monitor). 
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ment of other integrated and distributed network manage- 
ment products- 
System Overview 

A typical network consists of many nodes or computer 
systems. One (or more] of the nodes in the network is 
designated as the management node, and the other nodes 
in the network are referred to as managed nodes. The set 
af managed nodes can be connected to the network manage- 
ment node by a LAN, a set of point-to-point links ^ an X.25 
link, or a gateway. Fig, 1 shows this configuration and some 
of tlie major OV/NS Monitor modules, 
HP OpenView NS Monitor/Vectra (OV/NSM/Vectra). This 
portion of the OV/NS Monitor runs on the HP Vectra per- 
sonal computer and uses the HP OpenView Windows utili- 
ties to interact with the user and IPC software to communi- 
cate with the portion of the OV/NS Monitor running on 
the HP 3000. OV^NSM/Vectra's function is to provide the 
user interface. 

HP OpenView NS Monitor/3000 (0V/NSM/3K). This por 
tion of the OV/NS Monitor runs on the HP 3000 computer 
that is designated as a management node. This portion of 
the OV/NS Monitor interfaces with OV/NSM.'Vectra to ser- 
vice user requests, and it interacts with a module called 
the network control manager to retrieve network informa- 
tion from the managed nodes, 

HP OpenView NS Monitor/lPC (QV/NSM/IPC}. This soft 
ware provides transparent interprocess communication be- 
tween OV/NSM/\^ectra and 0V/NSM/3K. The IPC mecha- 
nism uses HP OfficeShare on the Vectra, and NetlPC^ on 
the HP 3000 to provide reliable communication between 
the HP VectK'i |3f^rsonaI computer and the HP 3000, 
HP OpenView Windows. HP OpenView Windows runs on 
the Vectra and provides a set of utilities and functions to 
display application menus and interact with the user. It 
provides a common user interface for all network manage- 
ment functions. 

Network Control Manager (NCM), I'he network control 
manager runs on the management node and handles com- 
munication with the network control server on the man- 
aged nodes, 

Nelwork Control Server. The network control server runs 
on the managed nodes and performs functions on the man- 
aged node in response to requests from the management 
node. 

HP OfficeShare. This application provides communication 
services hetween HP Vectra personal computers and HP 
3000 systems. 

The architecture of the OV/NS Monitor permits multiple 
management nodes to control oveHapping areas of the net- 
work — that is, two or more management nodes can receive 
data from the same node. The design also permits several 
Vectras to connect to the same management node and mul- 
tiplex the communications in an orderly manner Each Vec- 
tra can connect to a management node via a Li\N, a direct 
connection, or a modem. 

OV/NSM/Vectra requires a connection to the manage- 
ment node. If the user tries to perform a function that re- 
quires the use of the management node and the node is 
not already connected, a logon dialog box is displayed and 
the user is given an opportunity to connect to the manage- 



ment node. HP OpenView Windows does not provide any 
security of its own and expects each application to imple- 
ment the required level of protection. In OV/NSM/Vectra, 
users are authenticated as they try to log on to the manage- 
ment node. As part of authenticating a usern each user is 
given a level of security clearance at the management node. 
Three capability levels are recognized: reader, writer, or 
super user. If a user does not have sufficient capability for 
a particular menu item it is not selectable. This is done by 
a Microsoft Windows concept called graying out (dimming) 
the menu item. 

The following sections describe the overall design of 
0V/NSM/3K and OV/NSMA^ectra in more detail and pro- 
vide some insight into the operation of these applications. 

HP OpenView NS Monitor/3000 

To provide an extensible architecture that enables new 
di.stributed management applications to integrate easily 
with HP OpenView NS Monitor, a modular approach was 
employed to design the 0V/NSM/3K modules. For the high- 
level design, HP Teamwork/SA was used to create data 
flow diagrams and to validate the consistency of these dia- 
grams. For low-level design, finite state machines were 
used to design each individual module, and in some cases, 
state tables were used to settle several design issues* Since 
OV/NSM/3K is modular* a message-based interprocess 
communication (IPC) mechanism was adopted because it 
proved to be more flexible and easier to use than other 
alternatives, such as procedural IPC. Pseudocode and text 
specifications were also used to help promote and explain 
the design and interfaces between the modules. 

Operation of 0V/NSM/3K 

0V/NSM/3K is started by running a stream job after the 
network control manager and network control server soft- 
ware have been successfully started. The stream job sets 
up some file equations and logging options, and then starts 
the Monitor process^ which in turn starts other OV/NSM/iiK 
processes. Once initialization is done, a me.ssage is printed 
on the operator console indicating success or failure of the 
start-up process, 

O V/NSM/3K is stopped by executing a UDC (user-defined 
command) script. When this is done a HALT message is sent 
from the Monitor process to all of its child processes. Each 
process^ after receiving the HALT message, is responsible 
for cleaning up before exiting. 

Before any messages can flow between the Vectra and 
the management node^ a connection must be established 
between OV/NSM/Vectra and 0V/NSM/3K. A coimection 
is initiated when the user logs on to OV/NSM/Vectra. OV/ 
NSM /Vectra formats the logon request and sends it to OV/ 
NSM/3K. After validating the request, 0V/NSM/3K sends 
a confirmation logon back to OV/NSM/Vectra that indicates 
the connection is established and more requests can be 
sent from the Vectra to the management node. 

When the user invoktjs a network management service 
(e.g., Try Connectionh the request is sent to 0V/NSM/3K, 
which tries to establish a connection with the network 
control server on the targeted (managed) node. If the con- 
net :t ion is successfully establishedt the request is sent to 
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the network control sender on the target node. After process- 
ing the request, the target node will send back a response 
which is fomwded to the oser on the Vectra via OV^NSMi 

3K. 

As shown in Fig. 2. OV/NSM/3K consists of five process- 
es. The Monitor. Status, and Opt Logger processes are required 
to be running at all times. The Diag and Config processes are 
started when the user logs m and are terminated when the 
user logs off. All of these processes use a message-hased 
IPC mechanism lo communicate with each other. 

Monitor Process 

The Monitor process is the parent process of the other 
processes ia OV/NSM/3K. It ts started by the stream job 
described earlier. During initialization it starts the Status 
and the Opt Logger processes. The Monitor's primary function 
is to receive requests from any OV/NSM/V'ectia trying to 
establish a dialogue with the Config or Diag processes. After 
verification of the user password, the Monitor process 
spawns the Config or Diag processes and passes the informa- 
tion to them so that they are able to fjommunicale with 
OV/NSM/Vectra. Fig. 3 shows the data flows for settLngup 
a connection to a Config process. If there is a status or con- 
figuration change made, the Monitor fjrocess will broadcast 
the change to all the active Diag processes. Regardless of 
the number of Vectras running OV/NSM/ Vectra. there is 
onlv one Monitor process running at all times. 



OV/NSM/Vectro 




OV NSM 3K 



Status Process 

The Status process has two principal tasks: maintaining 
the state of each object that can be displayed on the network 
topalog>^ map and acting as a centralized collector of remote 
messages. The Smtus process changes the state of an object 
based on events received from local or remote nodes. 

An^iime a node changes state, the Status process sends 
a message to OV/NSMA'ectra (via the Monitor process) and 
writes a message to the event log. The Status process also 
conveys the state of all nodes to a Diag process on request. 

The Status process's second task of acting as a centralized 
collector of remote logging messages involves logging only 
those messages that it considers critical enough to be of 
interest. The Status process writes these messages to log 
flies, which are protected from being written to by any 
other process. Some messages that are sent to these files 
are generated by the Status process itself in response to 
time-outs or other locaJ events. 

Opt Logger Process 

The Opt Logger is the process that collects network perfor- 
mance dala* Its basic functions are to request the network 
control server on a target node to start a data collection 
run, stop a running data collection run, and collect the 
data produced by a data colle::tion run. A data collection 
run IS both the process of collecting network performance 
data and the storing of that data in a Turbolmage data base. 

Diag Process 

The Diag process provides the diagnostic functions for 
troubleshooting a specific network problem. The Diag pro- 
cess is started by the Monitor process when a valid logon 
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request is received from OV/NSMA/ectra. If the Diag process 
does not encounter an error, it will send a logon confirm 
message to OV/NSiVL/\''ectra, thus establishing a connection. 
After this, all messages to or from QV/NSMA/ectra will go 
tfuough the Diag process. 

There can be multiple instances of the Diag process run- 
ning at one time — one per Vectra connection. Since the 
Diag process is started by the Monitor process, it can also be 
brought down by the Monitor process via the HALT message. 
The Diag process can also terminate if it detects its connec- 
tion with OV/NSM/Vectra is broken or it receives an EXIT 
message from OV/NSMA^ectra when the user logs off. 

Config Process 

The Conf fg process implements OV/NS Monitor configura- 
tion functions that include user management and network 
topology file management. 

The Config process is started up by the Monitor process 
w^hen it receives a vahd logon with a request to start the 
Config process. Only one Config process can be active on the 
management node at a time. The Confrg process can be shut 
down in the same manner as the Diag process. 

Interprocess Communication for 0V/NSM/3K 

All OV/NSM/3K processes use a set uf IPC library routines 
to send and receive messages to and from each other, to 
set up a timer that causes a process to be notified when 
the timer expires, and to interface to NetlPC for communi- 
cation between QV/NSM/3K and OV/NSM/Vectra and the 
communication ports on the HP 3000. The IPC library pro- 
vides a uniform IPC interface and centralizes the IPC related 
code. Collecting all the IPC in one place enables the under- 
lying IPC mechanisms to be changed without affecting the 
other processes and having the .same IPC interface in all 
modules made it possible to integrate theOV/NSM/3K mod- 
ules with little difficuhy. The IPC library also minimizes 
the processing overhead that takes place on the Vectra side 
of OV/NS Monitor. This objective is achieved by using a 
fixed -size header in every message. Thus, the address of 
where function dependent data begins in a message can be 
easily determined by adding the fixed number of bytes 
representing the size of the message header to the address 
of the first byte of n message. 

HP OpenView NS Monitor/Vectra 

The OV/NSMA^ectra software is an integral part of OV/NS 
Monitor, yet it is distinctly different from the OV.'NSM/3K 
portion of OVTSTS Monitor in a few key respects. First, 
OV/NSM/Vectra runs on a single-user personai computer 
running MS-DOS*. Microsoft* Windows, and HP Open- 
View Windows. OV7NSM/3K operates and was developed 
on a multiuser HP 3000 business computer running the 
MPE V operating system. Second, OV/NSM/Vectra is the 
user interface portion of the OWNS Monitor, while the 
0V/NSM/3K software is used to monitor and control the 
nodes being managed by the user on the Vectra. Because 
of these differences, distinct requirements were developed 
for the OV/NSM/^ectra software. 

The basic strategy used to provide for extensibility and 

Microso^ and MS-DOS are U.3 registered iradematks ot Microsoft CnrporaEjon 



changes resulting from user feedback was to modularize 
the architecture based on the natural divisions present in 
OV/NSM/Vectra applications. While doing this, the con- 
straints imposed by both Microsoft Windows and HP Open- 
View Windows had to be accommodated. 

OV/NSM/\^octra is required to handle two main inter- 
faces: the user interface and the interface to HP 3000 soft- 
ware. The interface between the Vectra software and the 
HP 3000 software is message-based and the interface be- 
tween OV/NSM/Vectra and the user is arranged in terms 
of dialog boxes. Thus, the basic design clusters the parts 
for a particular activity into one module to create a specific 
interface to the user. This includes the dialog box and its 
associated resources, the dialog box procedure, and the 
message interface to the HP 3000. This arrangement is 
.shown in Fig. 4, Modules are as independent as possible, 
and each module assumes very little of its environment. 
Global state data is reduced to a minimum and, where 
applicable, is manipulated by access procedures rather 
than directly by the various modules. 

To help meet the goal of timeliness, code reuse was em- 
ployed and implemented in two ways: linkable libraries 
and extensive use of code templates. Code that is commonly 
used by many modules was put into linkable libraries to 
reduce tiode space use. For modules that were similar in 
structure but differed slightly in specifics, templates were 
created. Dialog box procedures are the best exEunples of 
this. All the OV/NSM/Vectra dialog box procedures have 
the same basic structure, differing only where required to 
perform the unique task or service provided by that box. 
This increased code size but leveraged large amounts of 
design and coding effort. 

Wherever possible, an attempt was made to exploit 
the features provided by Microsoft Windows. For example^ 
Microsoft Windows provides natural and easy ways of 
creating object classes called subclasses. OV/NSM/Vectra 
used this feature extensively to leverage the amount of 
original coding that needed to be done for the user interface. 
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OV/WSM Vectra Structure 

Each of the OV NSM'A^ectra applications consists of three 
separate processes: OV/TJSMVectraRun, OVNSM VectraDraw, and 
OV NSM/VectfaAUmin. This set of processes, together with the 
OV/NSM/3K processes, provides the OV/NS Monitor net- 
work management facilities. 

The division of functionality between the three processes 
is hased on the guidehnes recommended in the HP Open- 
View Windows Deveiopefs Kit Writefs Style Guide. A 
common applicatLon structure for developing the three pro- 
cesses was created without regard for the functional differ- 
ences hetween them. There are three areas of interaction 
in this common application structure with which OV/NSM/ 
Vectra is concerned: interacting with the user, interacting 
vrith the management node, and interacting wtth the net- 
work. 

Interacting with Users 

Interacting with the user requires OV/NSM/Veclra to in- 
terface with both Microsoft Windows and HP OpenView^ 
Windows, with the majority of the interaction taking place 
directly w^ith Microsoft Windows. 

Microsoft Windows Interface. Most of the OV/NSM/Vectra 
tasks are simple Microsoft Windows applications. They 
use the intrinsics provided by the Microsoft Windows 2.0 
Soft wo re Developer's Kit, and the standard Microsoft Win- 
dows objects such as dialog boxes^ menus, and icons. 

The most coEoinon operation performed by OV/NSM/ 
Vectra is to solicit user input and display user output using 
dialog boxes. The dialog box is used as a unit of modulari- 
zation in OV/NSM/Vectra. That is, a dialog hex, along with 
its dialog box procedure ♦ IPC routines, and printing 
routines, forms a dialog box module, Kach dialog box mod- 
ule i,s responsible for handling the requests and responses 
between the Vectra and the nicinagement node. It does this 
using the services of the transaction manager module and 
the IPC interface, which are described later. Fig. 5 shows 
this structure. 

Sometimes there was a need to modify the default be- 
havior of Microsoft Windows as in the case of the pre- 
defined window classes called controls. An example of a 
control is a single-line edit field that allows an application 
to display information to the user and receive input of any 
type from the user. The properties of controls can be 
changed by a process known as subclassing, which allows 
the application to iiiherit the current set of properties as- 
sociated with a control and modify those properties to 
create a new^ type of control. An example of a subclassed 
control is the password subclass, which is a single-line edit 
control that allows the user to input only alphanumeric 
characters, the first of which must be an alphabetic charac- 
ter. This subclass does not echo the keyboard input to the 
user. 

OV/TSJSM/ Vectra uses subclasses frequently. The benefits 
of subclassing to OV^TMSM/Vectra are twofold. First, OV/ 
NSM/Vectra adds syntax checking (o all of its new controls. 
Thus, syntax errors are detected ns soon as an incorrect 
character is entered rather than resorting to primitive, 
forms-based methods of reporting errors. Second, the use 
of subclasses allows OV/NSM/Vectra to add or remove func- 
tionality without having to create new controls from 



scratch, reducing the amount of time required for design, 
coding, and testing of new code. 

Some of the features of Microsoft Windows did present 
large design and Lmplementation problems during the de- 
velopment of OV/NSM/Vectra. One of these problems is 
that Microsoft Windows provides no true communication 
capabilities of its own, nor does it provide an interface to 
any of the connnonly accepted methods of communication 
for personal computers (e.g.. NetlPC or NetBIOS]. Integrat- 
ing one of these communication mechanisms into a Micro- 
soft Windows application proved to be quite a challenge 
and is described in more detail in the section on interacting 
with the network. 

HP OpenView Wiedows Interface. To operate in the HP 
OpenView Windows environment with other applications, 
there are certain standard Microsoft Windows functions 
that applications ask HP OpenView Windows to perform 
on their behalf, such as adding menus to the menu bar. 
This gives HP OpenView Windows some measure of con- 
trol to present a consistent look and feel to the HP Open- 
View enviroruneot. Applications use the intrinsics pro- 
vided by the HP OpenView^ Windows developer's kit to 
access these normal Microsoft Windows features, as well 
as some administrative tasks required to operate as an HP 
OpenView Windows application. 

HP OpenView Windows applications are unlike normal 
Microsoft applications in some respects. One difference is 
that the main window for an apphcation (the window most 
applications create when they come alive) is invisible. This 
window* has zero coordinates and is used for taking advan- 
tage of the messaging facilities of Microsoft Windows. It is 
known as a communication window and is created by mak- 
ing a call to HP OpenView Windows. The actual window 
displayed on the screen with the map and menus is wholly 
owned and operated by HP OpenView Windows. Since 
Microsoft Windows associates a message queue with an 
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application's main window and posts all messages dastinRd 
for an application to this queue, all messages resulting from 
user interaction with thy map and menu items are received 
by tip OpenView Windows. HP Open View Windows then 
forwards messages that arrive in its queue to the appro- 
priate application's communication w^indow for sub- 
sequent processing. 

Interacting with the Management Node 

The bulk of the OV/NS Monitor resides on the HP 3000 
rnariBgejnenlnode.TheOV/NSM/^ectraapplicationsestab- 
lish communication with the management node using TCP/ 
IP via the NetlPC interface. All communications to and 
from the management node are in one oi the predefined 
OV/NS Monitor message formats. The normal mode of op- 
eration is request/response oriented, with all requests being 
initiated from tiie OV/NSM/Vectra side. These requests are 
received and processed by 0V/NSM/3K and the results are 
formatted and returned to OV/NSM/Vectra. 

Tfiis appears to be straightforward. However, a funda- 
mental design feature of OV/NSMAV^ectra is that multiple 
requests can be outstanding on the management node, 
OV/'NSM/\^ectra cannot, therefore, block on any individual 
reply, A method of pairing requests with responses and 
associating these request/response pairs with their originat- 
ing dialog boxes had to be developed. To complicate mat- 
ters further, there are a few asynchronous event messages 
that originate on the management nodet such as the notifi- 
cation of the shutdown of tlie OV,TSfSM/3K software. These 
asynchronous messages have no associated dialog box, but 
need to be handled in as efficient a manner as any other 
response. Satisfying these requirements placed some addi- 
tional constraints on the design of the network interface. 

Interacting with the Network 

OV/NSMA^ectra handles the receipt and sending of pack- 
ets across the network by encapsulating netw^ork packets 
as Microsofi Windows messages to a dialog box procedure. 
This interface is defined and supported by two modules: 
the IPC library and tlie transaction manager shown in Fig. 5. 

The IPC library is a thin layer of software that interacts 
with the HP OfficeShare communications software. HP 
Office Share is divided into tw^o layers: the transport layer 
and the NetlPC/RPM layer. The transport layer supports 
either an HP Thinhan link or a serial link. Based on the 
physical connection between the Vectra and the manage- 
ment node, one of these transports must be loaded into 
memory by the user before running Microsoft Window^s. 
Only one type of link can be loaded at a time., and it resides 
in Vectra EMS memory." OV/NSMA'^ectra assumes nothing 
about the transport except that it expects il to he present. 
Since the transport software is sitting outside of Microsoft 
Window^s, there has to he a way of requesting data to be 
sent on the link. This is provided by a dynamic library 
included in the NetlPC/RPM development package. This 
library provides a standard NetlPC interface for use with 
Microsoft Window^s-hased applications. This is the only 
communications interface OV/NSM/Vectra deals with. 

Like the NetlPC interface library used by 0V/NSM/3K, 
OV/NSMA'^ectra's IPC library provides a set of procedures 
for accessing the NetlPC interface. Tiiese access procedures 



hide the complexities of connection establishment, termi- 
nation, and other network operation from the rest of the 
application, thereby allowing them to make simple open, 
close, readt and write calls to the netw^ork. 

The transaction manager is responsible for creating and 
destroying transactions associated with dialog boxes as 
well as distributing packets from the network along with 
a transaction identifier to the correct dialog box. Each 
dialog box procedure requests a transaction from the trans- 
action manager when it has a request to send to the man- 
agement node. The transaction manager associates this 
transaction, identified by a unique transaction identifier* 
with the dialog box handle. The packet Is then sent to the 
management node. The response to this request is also 
identified by the transaction identifier At some point the 
response packet is retrieved from the network by the IPC 
library module. It is given to the transaction manager mod- 
ule, which then looks at the transaction identifier and posts 
the message to the dialog box registered for this transaction, 
The dialog box procedure then processes the message as 
it processes all Microsoft Windows messages, completel}^ 
unaw^are that the message actually came from the network. 

Combining the Interfaces 

When HP OpenView Windows Is started from Microsoft 
Windows, the user is actually executing one of the HP 
OpenView Windows processes OVRun, OVDraw, or OVAdmin 
[see article on page 60). These processes will spawn all 
other Run, Draw, and Admin applications, respectively. For 
the OV/NS Monitor these include OV/NSM/VectraRun, OV/NSM/ 
VectraDraWf or OV.'NSM, VectraAdmin. The list of applications 
tibial are spawned is kept in the Microsoft Windows initiali- 
zation file WfN.INI alun^ with the location of the user's de- 
fault map, the NewWave help files ^ used by all HP Open- 
View^ Windows applications, and the time and date locali- 
zation information. 

When actions performed by the user on the HP OpenView 
W i n d o w s map are of i n i e re s I t o O V /N S M/V e ct ra , H P O p e n - 
View Windows forwards a message to OV/NSM^Yectra's 
communication window. In the order received, these mes- 
sages are appended to the queue and are processed, along 
wnth any other Microsoft Windows messages posted di- 
rectl}^ to the queue. 

Once the user*s selection has been passed to OV/NSM/ 
Vectra, HP OpenView Windows fades into the background 
and OV/NSM/Vectra makes calls directly to Microsoft Win- 
dow s to display dialog boxes, solicit user input, and display 
results. OV/NSM/Vectra requests are packaged into IPC 
packets and sent to tbe management node. When the re- 
sponses are returned from the management node, they are 
received by the HP OfficeShare transport. When the net- 
work polling mechanism in OV/NSM/Vectra discovers that 
a packet has been received from 0V/NSM/:1K, it copies the 
packet contents into its own data space. The transaction 
manager then reads the packet header to locate the transac- 
tion identifier to determine which dialog box should re- 
ceive tlie packet. Once it knows where to send it. the trans- 
action manager encapsulates the packet into a Microsoft 
Windows message and posts it to tlie dialog box that origi- 
nated the request. Once this message is received by the 
procedure associated with the dialog box, the message is 
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disassembled and its results are displayed Id the dialog 
box display area. 

If the ttansactiDn manager discovers, after reading the 
packet header, that the packet contains an asynchronous 
message rather than a response to an earlier dialog box 
request, the packet is encapsulated in a Microsoft Windows 
message and passed to the 0\WSM Vectra asynchronous 
message handler for further processing. 

Cone t us ton 

Developing the HP OpenView NS Monitor applications 
helped to identify the common functions that are required 
to provide a framework for the development of distributed 
and integrated network manai^ement functions. We found 
that it was essential to provide a common interprocess 
communication facility between the user interface, the 
management node, and the managed nodes. In addition ^ 
validation of users and their access rights, handling of 
events and status momtoring, and data storage and retriev'^al 
must be designed and developed uniformly to support the 
needs of all applications that are to be integrated. 
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S^KAodular Uqufd Chrom«togriph : 



Herbert W led erader served 
as both section manager 



Herbert Wiecieroder 

mf ^ ^Tfc - ^^^ projeci manager tor 




I the HP 1050 liquid ctirch 
malograph project at tfie 
Jr Waldbronn Analytical Dtvi- 
^ sioni, PreviQusly, he was a 
I project manager tor ttie HP 

1090L liquid chromalo- 
I graph and devebped 
hardware and software for the HP 1090M arrd HP 
T0B4B Herbert joined HP in 1977. the year he 
graduated from the Technical University of Berlin, 
earnmg a diploma in electrorti^csand computer sci- 
ence. He atso IS 3. graduate of FactihochschuteUJm 
(1974) wish a degree in engineering. A member of 
Gesellschaftfur Informatik. Herbeifsprofessianal in- 
terests are centered around controJ systems and ap- 
plications (or analytical instruments. Born in 
Stuttgart, he resides in Spielberg with his wife and 
two children He enjoys tenms. skiing, and traveling. 



11 LC Quality Eiiglrwaringl 



Helge Schrenker 

si^^^^^^^^^H HeigeSchrenker was HP's 
^^^P^^^H Waldbronn Arcalyticar Dm- 
^^^^^^^^H sion quality manager dur- 
B^|ttSi^^H ir^g development of the HP 
^^^^^^^^1 t Q50 1 i q uid c h romatograph 
i^^^^^^H system He joir^ed HP in 
__^^^^^^^^^^ "' ^"^^ 3S ^ product markel- 
^^H ^S ^^^ "^9 manager In 1979. he 
^^B ^r ^^1 became an R&D group 
^^V ^k. ^H leader investigating flow 
control systems ana dokng systems integrat>onfor 
the HP 1 030 high-performance liquid chromato- 
graph. In 1983. he became a quality assurance 
manager Hesge earned an applied physics di- 
ploma (1967) from Kiel University He has written 
several technicaJ articles on pH measurement and 
control, concepts of fast-liqujd chromatography, 
ftow control in high-performance liquid chromatog- 
raphy, and I he effect oJ mohiie phase preheating 
on liquid chromatography performance H«s work 
has resulted in patents on a riow-conlroKed high- 
pressure pump and a column thermostat lor high- 
performance fiQUid chromatography Before join- 
ing HP. Hefge worked in technical marketing sup- 
port for Philips Electronic Industnes, and served in 
the German Air Force. Born in Marbach. West Ger- 
many, heand hrs wife live in Karlsruhe. Hts hobbtes 
and interests include photography, bicycling, en- 
vironmental protection, and alternative traffic 
concepts, 




Wolfgang Wilde performed 
reiiability engineer]ng tesJs 
during development of the 
HP 1050 liquid chromalO- 
graph system, He ts cur- 
rently tine quality engineer- 
ing manager tor HP's 
Waldbronn Analytical Divi- 
sion. He earned a diploma 
(1966) in physics from the 

University of Mainz in West Germany, and jomed 

HP in 1987 as a reliability engineer 

17 — LC Ssmpl« Injtetor/ Auto<Mmpl«r 




Gerhard Pie 

Gerhard Pie served as proj- 
ect leader tor the auto- 
sampler for rhe HP 1 050 liq- 
uid chromatograph system 
and was responsible for HP 
1050 firm ware develop- 
ment In a prior HP position, 
he developed electronic 
hardware and lirmware for 
the HP ^090 autojnjecior. 
autosampler. and pump contigurati'On Gerhard 
joined HP's Waldbronn Analytical D^visson m 1979, 
after receiving his electrical engineering dipioma 
from the University of Karlsruhe that year He was 
trom in Neusiadl, West Germany, and currently re- 
sides in Karlsruhe, 



Wolfgang Kretz 

R&D project engineer 

Wolfgang Kretz served as 
project leader lor the 
mechanical design of the 
HP 1 050 liquid cbromato- 
graph autosampler He 
also was project leader tor 
development of the autoin- 
jector for the HP 1 090 liquid 
chromatograph, de- 
veloped improvements for ttie HP 79341 A injector 
system, and served as a production engineer tor 
the HP 1O90 Wolfgang received his mechanical 
engineenng degree (1972) from the Fachhoch- 
schule Konstanz, and an engineering diploma Jrom 
trie University of Stuttgart m 1978. She year he 
joined HP. Born m Buchheim. West Germany, 
Wolfgang now lives m Waldbronn with his wife and 
two children Hjs hobbies include photography, 
reading, hiking, and astronomy 
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Klaus Witt 




Klaus Wm contrlbuteo to 
the design of the pump 
driver and conlrol system 
tor the HP 1050 liquid chro- 
matograph system He is 
now a group manager 
within R&D He joined HP ^n 
1979 as an R&D engsneer 
in the Waldbronn Analytical 
Division, stiertly after 



graduating Irom theFachhochschuie OsnaPruecK 
with an electronics diploma. At HP, he helped de- 
sign Ihe digital servo chip for the high-performance 
liquid chromatograph. He is named an inventor in 
a paten! application for a variable- stroke pump 
Born in Nedim. Germany (now Poland). Klaus 
served 15 months in the West German Army, and 
now resides in Keltern, Germany, WJth his Wffe and 
two children His hobbles include raising horses 
and horseback riding, 



Fred Strohmeler 

Mechanical englr^eering 

and hydrodynamics are the 
professional interests of 
Fred Strohmeier, section 
manager with HP's 
I Waldbronn Analytical Divi- 
sion . He helped design the 
HP 1050 and HP 109O liq- 
I uid chromatograph sys- 
: tems^ and is currently the 
project leader tor the HP 1050 pumping system, 
Fred, who joined HP in 1979, is named an inventor 
in patent apphcations for a pumping apparatus to 
deliver liquid at high pressure and for a sample in- 
jector for liquid chromatography. He received his 
engineering diploma in 1 979 from the Fachhoch- 
schule Kartsruhe. Born in Baden-Baden, Fred re- 
sides in Rheinmuenster. West Germany, with his 
wife and child. He enjoys jogging, canoeing, and 
reading, 
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Axel W\Bse 

A year after earning his PhD 

degree in physics and 
physical chemistry in 1977, 
Axe3 Wiese joined HP's 
WaJdbronn Analytical Divi- 
sion . He developed ^he HP 
793 54 A mulCi wavelength 
detector for the HP t050 
liquid chromatograph sys- 
Serr«. Before that, he de- 
signed the HP 79B8tA fitter photometric detector 
and the HP 1G46A fluorescence detector Now a 
program manager. Axel has authored several tech- 
nical papers in [he field of mccrowave instrumenta- 
tion. He resides in Karfsruhe. West Germany, and 
his hobbies include traveling and archeology 



Konrad Teitz 

Pro|ect manager Konrad 
Teitz helped develop the 
HP 79853 A variable 
wavelength detector, 
which IS pan of the HP 1 050 
liquid chromatograph sys- 
tem. 1 n [he past , he has de- 
— ^^^»^^' veioped other detection 
limU^^BKfti ^V^l^ems for the liquid chro- 
ttHnBRvVjf!f A matograph rnstruments 
produced at the Waldbronn Analytical Division, He 
joined HP in 1973 in Bbb=ingen, West Germany, 
and is named an inventor in a patent concerning 
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d new type of ultraviolef absorbancedeiectiof . Ws 
professional miefests include eiectrunlc circuit 
simuSaUcxiancf EMC Konrad. wrK> received an en- 
gineenng dipJOma in 1973 fnxn the UnrvefsJty ot 
Kartsruhe. West Gemiany, was bom r^m 
Uppstadt arid ncjw cesides m Kartstsad wilti his 
wife and son He enjoys backpacking pbotog- 
rapliy, and amateur radao- 



GQnter Koschete 

Gunter Hoscheie de- 
ve'oped data process ing 
fnnwa/efor theHP1050 

liquid chramatogfapti sys- 
tem. He also helped de- 
velop the ^P 1 040A defec- 
tor and HP 79801 A detec- 
-ir data acquisition 
■ .3rd ware and firnnware 
ijnter [oined HP m 1979. 
Q from Stuttgart University 
with an elect ronics diploma. A(\ R&D engineer wjth 
HP's Waldbronn Analytical Division, his profes- 
sional interests are Jast data acqupsition and pro- 
cessir>g. Born m Stuttgart. Gunter currently resrdes 
in Lang enstein bach, Wesi Germany He enpys 
reading. high-fideMty mustc, and btcycle riding 



Volker Brombacher 

VoikerBrombacher contrib- 
...led to the development o! 
;■ H analog 'to-digital con- 

rna»^^^^H vcrter for the multiwa^/e- 
' l_j ^ ^^B length deiectof and (he I/O 
^HBHj^^H and diagnostic firmware for 
a'^^^K^^M ^'^^ ^^ ^^^^ ''^^^^ ^^^^ 
rnatograph sysEem. He is 

currently an R&D project 
leader in the Spectroscopy 

sectionot the Waldbronn Analytical DEVision. \^oikef 
earned an engineering dipiotna m electronics irom 
the Technical University ot Karlsruhe in 1985, pn- 
ing HP shortly after graduation. He was born in 
Pforzheim, West Germany and resides m PfmztsE 
w(th his wife and two children Volker's hobbies in- 
clude photography, an aquarium, molorblking, 
meditation, and yoga. 



CHit techr^iogy Bom m Off enby rg . Hubert resides 
in Waidbfonn with his wrfe and tno dniidren He en- 
pys tennis skiing and woodworking 







Hubert Kuderer 

Hubert Kude re r developed 
the mull wavelength detec- 
tor lor the HP 1050 liquid 
chromatograph system He 
has also designed froni- 
end electronics for the HP 
1040A detector, and 
worked tn quality assur- 
ance and manufacturing 
engineering Altar receiv- 
ing an engmeermg diploma from the Fachhoch- 
schule Oftenburg, West Germany, In 1978, he 
joined HP He has authored technical |ournal arti- 
cles on spectograph sensitivity, photodiode array 
spectrometers, and photodiode architecture, and 
he IS named art irweriior in two patents in PDA read- 
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Ghftstlan Butlr^r 

Soon after he received his 
engineering dtptoma in 
e{ectronics [1981 J from 
Facbhochschule 
Esslingen Chnstjan Butt- 
ner joined HP s Waldbronn 
,^^^^^^^^ Anal ytical Division in 1 98 1 
\ ^V^^^^^l He designed and im- 
^ M ^^H pEemented firmware for the 
HP 1050 liqiiid chromato- 
graph system Hehasalsod esigned ti r m wa re for 
the HP 1090 local user interface, and for the HP 
1040 detector. Asa project manager, he currently 
is working on HP 1050 communications and 
Irrmware enhancements. Christian was born in 
Stuttgart, West Germar>y, and now lives with his 
Wife and two children in Wafdbronn He enjoys 
table tennis, bicycling, and amateur theater 



Fromut Fritie 

■ ^^^■j After studies at the Uni ver- 

^■^^Bf sity of Karlsruhe m com- 

puter science, and gradua- 
Ijon ffom the Fachhoch- 
schule Karlsruhe (1982) in 
e lect ro n I c eng i n eeri ng , 
Fromut Fntze joined HP m 
1982 He designed operat- 
ing syjstem software and 
tools for the HP 1 050 (squid 
chromatograph system Before that, he designed 
hardware and soltware for the HP 1 090 liquid chro- 
matograph system, a remote control standard, and 
Pascal ChemStaiion software. Now a pro|eCf 
leader, he js working on a revishon control system 
and software quality His professional interests 
center around operating systems and Odject- 
orienied techniques Born in Heidelberg, West 
Germany, he and his wife live in Karlsruhe His hob- 
bies include photography, traveling, and desktop 
publishing. 



Gerhard Pie 

Author's biography appears elsewhere in this 
section 
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Born in Great Falls, Mon- 
tana, Tony Ridolfo received 
his mathematics education 
at Wabash College (BA de- 
gree m 1966), Ohio Univer- 
say (MS in 1 968). and Jowa 
State University (PhD in 
1975) After leachmg 
mathematics and com- 
pvter science as a profes- 



sor St Murray State Universtty m Kentucky, tie 
(Oiried HP in 19?6 and developed fmnware for a 
number of HP's caJculaiors He also served as a 
propd manager for ttie HP 75C computer s operat- 
rng system Tony coauthofed an HPtloumai arttcie 
on the HP 75G m 19S3 As a protecl manager on 
the HP Open View project, he started devetopment 
of HP OpenVrew Windows and later led tt>e de- 
velopment of the Open View NS performance 
monitor He i s a memper of the Soc fety f or I nduMf i al 
and Applied Maihemalics, and the American 
Mathemai]cet Society Tony lives m Saratoga, 
CaJifornia, wfth his wife and three teenage children, 
IS active in the Boy Scouts and as a referee in youth 
soccer. His leisure acti\fities include golf, skiing, 
and bridge 
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Keith S. Klemba 

^^^^. I mfonnation networks are 

^^ ^^^k 1 the prima ry p rof essio n al I n- 
M ^fc-j^^l I terest of Keith Klemba, a 
W^^^^' ^(^W I member of the Inform a! ron 
^'^■•' ' Networks Group technical 
staff who helped develop 
the HP OpenVew network 
management architecture, 
HfS other professional in- 
terests sncJude tDroadcast 
and space information netwohcs. He joined HP's 
Network Architecture Lab m 19ae. Before joining 
HP. he was a product manager with Vitalink Com- 
munications Corporation in Fremont, California, 
and a sysiems engineer and technical director with 
Sffl Iniernattonal m Menlo Pa^K, California. He re- 
ceived an A A degree ( 1 970) in computer science 
from DeAnza College. Keith authored a technical 
paper on HP OpenView architecture, published m 
the 1969 proceedings of the iFiP In 1957, he 
served a tour of duty in Vietnam with the U.S, Army. 
He is a member of the IEEE, and a commissioner 
for the police athleric league's girls' softball for the 
city of Santa Cfara. Married and the father of two 
children, Keith was born in Chicago, Illinois, and 
now lives in Banta Clara, California His hobbies in- 
clude raising 4-H guide dogs for the blind. 



Hul-LIn Lim 

^^^^^ I As a member of the techm- 

^^^^^■j c al si aff i n the Network A r- 

BP^^jI chitecture Laboratory in 

|r5^i^^ HP's Information Network 

' .W-- f Group, Hui-Lin Lim heJped 

^^^ '* j Open View network 

^^^' ' ii'anagement architecture 

:ai^ I !e joined HP s Smgapore 

- ^^ Network Operations group 

in 1969. Before that, he developed office systems 
and wrote programs for the National Computer 
Board m Singapore His professional interests in- 
clude the UNIX operating system and personal 
computers Hui-Un earned a BSc degree (1983) 
in computer science from Queen Mary Coilege at 
the University of London m the United Kfngdom, 
Born in the Republic of Singapore, he lives m Santa 
Clara, CaJifornia, with his wife and child. He enjoys 
photography and science fiction. 
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Maureen Mellon is Iheproj- 
eci manager of a group re- 
sponsible for developing 
HP Open View network 
managemont architectufe. 
Maureen pmed HP in 1 989 
and managed four network 
archrrecture specialises on 
tfiis project She received a 
BSEE degree (1975} from 
Vilianov^ Universi^.y in Villanova. Pennsylvanja, an 
M3EE degree (1976) from Drexel University in 
Philadelphia, Pennsylvania, and performed addi- 
tional graduate work to wards a PhD ( 1 989) at »he 
University Of California at Los Angeles. Before join- 
ing HP, Maureen worked on ISDN and broad bants 
J SON for AT&T Bell Laboratories in Hot m del, New 
Jersey. An editor of CCfTT recommendation Q 71 4 
on signaling system No. 7. and coauthor of a book 
on economic characterisations of large telephony 
networks, Maureen is a. member of the IEEE, and 
Eia Kappa Nu' and Tau Beta Pi societies. She was 
bom in Darby, Pennsylvania, and lives in Cuper- 
tino, Califorfiia. with her husbarid She enjoys skt- 
ing, tennis, running, and hiking. 



Mark L. Hoerth 



Mark Hoenh is the produce 
manager for the HP Open- 
View network manager 
server on the HP-UX 
operatfng system. After 
joining HP tn 1987, he 
served as the product man- 
ager for instrument support 
at HP s Product Support Di- 
vision. He received a BS 
degree (1985} *n electrical engineering from the 
University of Nebraska, and an MBA degree ( 1 987) 
from Stanford University. Mark was bom m Rapid 
City. Soutti Dakota, and now resides wish his wrfe 
in Stanford. California. His h^obbes include photo- 
graphy swimming, racquetbaJL and running 
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Arthur J. Kulakow 

Arthur Kulakow developed 
the graphics library and the 
map routines used m HP 
Open View Windows. He is 
now researching methods 
thai will enatjse software 
deveipers to use C-t- -i- m 
the development oi net- 
work management plat- 
.-u forms . Before joi n i ng H P in 

1985. Art was a software engineer with Bell 
Laboratories in NapervilEe, Illinois, and at Digital 
Research Company in Monterey, California. He 
earned aBS degree (1980) and MS degree (isez) 
in computer science from the University of Wiscon- 
sin in Milwaukee He is a meml^er o! ACM and his 
professi'Onal interests include user interface de- 
sign, objecf-oriented programming, and computer 
graphics. Born «n Milwaukee, Wisconsin. Ah lives 
in San Jose. Caiiforn»a. He enjoys scuba diving, hik- 
ing ^ campfng. and aerobics. 




tCsthleen L. Gannon 

■■■'i^lhleen Gannofi worH'ed 
r an R&D software en- 
gineer in the devefOpment 
of the HP Open View Win- 
dows/MS-DOS system. Be- 
fore that. Kaihy was a sys- 
tems er>gineer at HP Labs 
She began her HP career 
as a product marketing en- 
gineer lor cooperative sup- 
port products in 1 980 She earned a BS degree 
(1 980) in induetnal engineering from Norfhwestem 
University in Evanston. lllino<s. and an MS degree 
(1985) in elect heal engineertng from Stantord Uni- 
versity. Born in Pittsburgh, Pennsylvania, Kathy is 
married and lives eo Santa Clara, California. She 
has been an active memberof the board of direc- 
tors of the Santa Clara VaUey Science and En- 
gmeenng Fair for the pasi five years. Hernobbses 
and interests include needlework and science fic- 
tion 



Catherine J, Smith 

Catherine Smith is the R&D 

■^^^^^^H p roj ect ma nage r for rh e H P 
K^ ,J^^B' OpenView Windows/MS- 
' "^.^^^B ^^^ product Prior to thai, 
she served as project rnan- 
agerfortheHPtViPEXLtor- 
mtna.1 subsystem. Catherine 
joined HP m ^978, soon 
after she graduated trom 
the University of California 
a! Berkeley with aBS degree in eleciricaJ engineer- 
ing and computer science. Born in Yakima, 
Washington, she resides in San Jose, Caliiomia. 
Catherine is married and has one son in cotlege. 
Her hobbies include downhill skiing and hiking 
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Tamra I. Perez 

Developing lirmware and 
network software are 
Tamra Pere^' major profes- 
sional interests She de- 
veloped the network inter- 
face for the HP Bridgeman- 
ager project, and is now 
designing a user interface 
to manage HP's new high- 
speed and remote bridges. 
After pining HP in 1906 in the Roseville Nefworks 
D.'viston, she codeveJoped a wire test tool for HP 
StarLAN-l products Before that, Tamra worked in 
IBM's disk technofogy division as a summer intern 
ioT two years She earned her BS degree ( 1 986} in 
computer engineering from San Jose State Univer- 
sity, and will receive her MS degree in computer 
engmeering from UC Davis in June t990. Tamra 
was born in San Jose. CalEfornia. and lives m 
Roseville. She is a member of the Svi/eet Adelines 
women's singmg quartel, a flute player, and a 
member of the Tau Beta P» Engmeerkng Honor So- 
ciety. 



Andrew S. Fraley 

I After designing and im pie- 
meming LAN hubs, PC LAN 
cards, and drivers, Andrew 
Fraley worked on the de- 
sign and development of 
' ihe HP BridgeManager's 
user interlace. Andyjomed 
HP's Roseville Networks Di- 
vision as a design engineer 
in 1986. soon after earning 
a BS degree f1 966) iri conn pule r science from the 
Massachusetts Institute of Technofogy. Born in Col- 
umbus, Ohio, he and h?s w^fe reside in Citrus 
Heights, Caliiomia Andy enjoys soccer, skiing, 
tennis, and guitar, 
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lUtichael S. Hurst 

Michael Hurst joined HP in 
^flBh^ the Queensterry Telecom 

g^^^^^k Division in Scotland shortly 

I I after he received his 

r'#*y\*'^>^ Bachelor of Science de- 

^ gree with honors (1976) in 

computer science from 
'^^' Edinburgh University in' 

f Scotland. Mike was the 

project manager for the HP 
Open View data line monitor software. In the past, 
he designed microprocessor hardware and 
firmware for the HP 3779A^'B and HP3776A'B pri- 
mary multiplex test sets, and HP 1000 application 
software lor the HP 371 OOS remote access and test 
system. He is currently directing new develop- 
ments for the HP 371 OOS system. Mike (s a member 
of the ACM and she Shtish Compuler Society, 
where he serves on the Edinburgh Branch Commit- 
tee. Born in Wiltshire, England, he resides m Edin- 
burgh, Scotland, where he enjoys skiing and run- 
ning One o! Mike's ambitions is to spend two 
weeks skiir^g in Colorado 
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Serge Y. Amar 

I .As the technical leader in 
the development of the HP 
OpenView Datacommuni- 
cations and Ternninal Con- 
' troller (DTC) manager. 
Serge Amar was respon- 
sible lor its overaJI destgn 
' and implementation. He is 
now a projeci manager for 
the OpenView DTC man- 
ager. Before that. Serge was a foreign service em- 
ployee with HP's Information Networks Division in 
Cupertino. California, He developed Ihe DTC man- 
agement module for Ihe first release of MPE XL 
prior to pining HP in 1983. he designed electronic 
credit cards for home banking for Honeywell Bull 
Co. Serge received his diploma in electronics 
(1979) from Orsay Unrversity south of Pans, Born 
in CoJemb-Bechar, Algeria, he now lives in Greno- 
ble, France, with his wife and two children . His pro- 
fessional interests include personal computers ar>d 
network management, and his leisure time actlvh 
ties include skiing and diving. 
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MIchele A. Pneur 

^■^^^^■^^^Hj Michat€ Poeur helped 
^^^^^^^^^^1 "develop ihB HP OpenVj^w 
^^^^^^^P^^H Dai^communications and 
^^^^^^^^^H Terniin3> Control Fsr (DTC) 
^^l^^*^ ^^H '^^'^9^^ Joining HP £ 
^^If ^1 Grenoble Temrtinai Division 

^^v^ t n Grenobie France in 

B^ -^ '380. she worked as a de- 

BBjL^ ' ^HC^9 vefopmient engmeef TOf the 
■S^K^fc^B^I HP 2392A tenrnnal aricl as 
-j'_-. .,_ ^^j:.' iD*HPAdvanceLink S^isnow 
a. project msnager in rhe deveiopmerit of network 
management systems She recefvecf aii engineer- 
ing diploma (1980J Jrorri the Eccle Superseure d' 
Electricfie Bom in Lyon, Frarx^e. Miche^e and her 
husband and chifd now reside in Grenoble. She en- 
joys horseback riding, reading, and sports 



»S^ 



Usa M. Cole 

^^^■■■H A graduaze df Mer nmack 

^^^^H^Z Cdtege in Noun ArKfover 

^^^^B^^^k ^!a]ne. Lisa Cole eanied a 
HHqi ^^^ ^^ degree (19B3] in corTi- 
^^H 1M_ ^^L outer science Aftei lOining 
^^K^^^^^^^ iiPfn1967asades[9ner!- 
i^^^k^^^^y^ gineer. she worked on the 
^^^^^^^ /eclra portion of the HP 
"— — Open V lew NS Mon itor . and 

4 <s now developing security 
software for thecomrrxjnicatTons portion of Open- 
View Previously, she worked on network manage- 
ment Wflh Digital Equipment Corporation, on com- 
munications applications and SNA with Wang 
Laboratorjes ^nc., and on compiters with Hon- 
eyweU Inlonrnatian SysJams Lisa's professional 
interests include network management and 
standaros-based communications. A native of 
Salem Massachusetts she lives in Scotts Valley, 
California, She and her husband are expe-ctrng 
tneif first chifd sn June Lisa enjoys skiing, travel, 
and handicrafts. 




AtuI R. Garg 

A project rttaAagef lor the 
HP OpenView dfstnbuted 
network management ser- 

vri:es. Atul Garg has 
worked in tne area of nel- 
vtfork pfotocofs and ar- 
chitecture since he ^ined 
HP in 1961 He worked on 
HP AdvanceNet artd on 
HP's desfcgn of the internet 
arcnitecture and IEEE Standard 802.3 He also 
coniribuied to the devetopmeni of the disfribuled 
ISiS monitor applications under OpenView Atyl 
coauthored anarticFeon HP Ad vanoeHet in the HP 
Journal in October, 19B6. and published anott^f 
article on t_AN internet protocols for a Midcon con- 
ference in 19BZ He earned a bachelor's degree 
(1979) in electrical engineering from the Indian In- 
stitute oF Techno logy in Kanpur, India, and an I^S 
degree {I98t) m eiectncal engmeenng from the 
Uni\^ersfty of Hawaii in Honolulu Born m New Delhi, 
India, Atul lives in Santa C^ara, Calitornra, with his 
witeand daughter Hishobbiesi'nciude badminton 
and bridge 
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